text:
Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ
September 12th, 2010 by lucas
A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I'm trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers.
Myth: Ruby is completely outdated in Debian and Ubuntu
There's a culture in the Ruby community of always using the latest bleeding-edge version. There's also a culture (though this one has recessed a bit, I think) that it's perfectly fine to change APIs in incompatible ways if it makes the software slightly better.
In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won't be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that's basically all. So it's not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version.
In development branches, we are following the latest upstream versions quite closely. Debian 6.0 'squeeze', to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august).
There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody.
We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source.
We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time.
Myth: Ruby is split into a myriad of packages in Debian
In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:
- the size of some libraries, like REXML
- the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
- licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.
Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:
- ruby1.8: binaries (ruby itself, irb, rdoc)
- libruby1.8: the standard library, except ruby-tk
- libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
- ri1.8: contains both the ri binary and documentation
- ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
- ruby1.8-elisp: Ruby emacs mode
- ruby1.8-examples: Examples
- libruby1.8-dbg: debug symbols
It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones).
Myth: Rubygems is crippled in Debian
There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as "state" for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don't think that it's reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems' binary are outside of $PATH. After the change, gems' binary would also be installed in /usr/local/bin.
gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow
gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message.
Myth: Ruby is slow on Debian
Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same.
There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn't even a bug report about it!
After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since 184.108.40.2069-2. (So the Debian package is actually newer and faster than upstream Ruby in that regard).
What makes Ruby so difficult to maintain in Debian?
The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD.
Why doesn't Ruby use the alternatives system on Debian?
The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis.
However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There's nothing impossible to do about that, it just needs someone to do the work.
Where do we go from here?
The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable).
This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I'm the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team.
While I haven't reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.
56 Responses to "Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ"
Eugene wrote on 09/12/10 at 3:20 pm :
Ouch, demotivating for sure.
Also, ruby-lang.org state that 1.9.2 is "mostly compatible" with 1.9.1. Is that mean they are non fully API-compatible?
Lucas wrote on 09/12/10 at 3:29 pm :
@Eugene: Indeed, there are some changes that can prevent working code on 1.9.1 to work on 1.9.2. For example, '.' is no longer included in the load path, so relative requires need to be explicit. Whether this is an API breakage or not is questionable.
Rodrigo Rosenfeld Rosas wrote on 09/12/10 at 3:32 pm :
I think the main reason why people complain about Debian packages is because rubygems seems to be broken. When rubygems binaries work out-of-the-box and in the default paths and "update –system" is allowed, I guess many Ruby users will use the Debian packaged version since there is no need to compile anything… Besides that, several gems require a compilation phase and maybe merging ruby and ruby-dev would bring less surprise to newcomers trying to install their gems…
Anyway, the main reason I prefer RVM over Debian package is the gemset feature. There are also great features in RVM. A single command changes your environment from Ruby 1.8.7 to 1.9.2 to JRuby 1.5.1… The rake tasks and Ruby scripts just work and I don't need to worry about what executable to run. Actually, the main disadvantages of using RVM is that the compile phase is slow and that the ruby packages don't get updated by 'apt-get dist-upgrade', which I do on a daily base in unstable repository.
But I also have the Debian Ruby installed and it is useful, for instance, when I need to compile some Vim extension that needs exactly the same Ruby version for which vim support was compiled with (like the great command-t vim script).
I can understand you are sad and demotivated, but I think there is space for both approach: system packages and RVM management. RVM really easy the migration path from Ruby 1.8 to 1.9 making it trivial to change our environment and allowing us to isolate gem versions. But after development is finished, system packages are faster to install and better integrated with Debian upgrade tools (this is the reason why I won't be buying any Notebook with NVidia graphic cards anymore).
I would just like to thank you for your efforts and suggest you to make the rubygems work in the standard way (default paths, updates, etc) and I guess Ruby developers will cease Debian's packages attack.
Congratulations for your great work!
Thank you!
Steve McIntyre wrote on 09/12/10 at 3:33 pm :
Ick, Ruby sounds like a mess. Given what you've written here, I wonder why anybody would want to use it… :-(
terceiro wrote on 09/12/10 at 3:34 pm :
I wonder whether the harsh attitude towards Debian is from people who actually do things and could otherwise cooperate with us, or from random people who rant without actually knowing what they are talking about.
Losing you in the pkg-ruby-extras teams would be a major defeat for everyone who cares about Ruby in Debian.
raggi wrote on 09/12/10 at 4:31 pm :
It does have to be realised that the bin wrappers outside of path problem is one that does really get in the way of the 90th percentile use cases. It's very clear that this is one of the really major if not the major source of hostility by users. I'm glad it's under discussion to move it back to /usr/local, and I provided feedback on the rubygems-developers list after getting the teams messages through by putting pressure on the ML moderator. As you know I'm doing what I can to be a responsive guy on the 'other side' of this, but I'm also trying to avoid more breakage, and as such I've scheduled a lot of the required integration patches / fixes for a February sprint in order to make sure we have ample time to research the plans such that we don't break things for other packagers (besides Debian, that is). The result should be a system that's more friendly for everyone.
To be quite honest, the comment about smartphones and embedded systems is really an odd one. I don't know of anyone in the ruby community who can use an unpatched, custom built ruby for these purposes anyway. Certainly the Debian / Ubuntu patch sets do not make the interpreter suitable for these use cases either, and as such I really see this as a boilerplate argument that doesn't really have practical applicability. The most essential and foremost item bearing discussion would be the GC tuning that has to be done in these low space / low cpu / low ram scenarios. You'd probably also want the MBARI patches too. I'm not saying this to start another argument, I'm just saying it to point out that some of the people who turn hostile will not be helped to calm down when they read statements like this when they know them to be invalid.
You know I'm trying my best with what time I have to try and repair relationships or at least be somewhat of a channel to at least sympathize with your issues on the RubyGems side of things, and I'm doing what I can to try and push core toward more sensible engineering processes, but we have a lot of work to do to reduce ill feelings on both sides. In the past we've all mentioned facts to each other that have caused an immediate defensive attack from the other side, and it's going to take concerted efforts on both sides to stop doing that. I can't make assurances for you that other members of the community will respond in kind, but I do have a little weight with them to at least try to calm the situation and ask them to step back and let me handle some of the issues. I just need to hope that I can provide you and the software with the time required.
The RubyGems issues raised by gemcutter also did a massive amount of damage to reputations, as it caused a complete breakage for end users. They couldn't install new gems using old RubyGems and because of the patches and release processes in their OS they couldn't get new RubyGems without doing upgrades to the whole system. Obviously for these end users that was in many cases unacceptable. We can argue all day long about how wise/unwise those users decisions are, and philosophy about which facets of the different approaches are correct. None of this actually matters, in reality. Yes, the changes introduced by gemcutter were awful release engineering and caused a final-blow set of issues that are still appearing in the wild regularly. I spoke out against all of this at the time, but even being a committer to RubyGems and one of the folks that devotes a lot of time to community support, no one listened. I received hostility because I was speaking out against the latest shiny thing. As I've said on ruby-core recently, this attitude and this immature release engineering is almost unforgivable, but we have to. We have no choice, if we want to support users and help people get real work done, we have to move forward and make these issues go away somehow, or at least ease transitions. We cannot really afford, if we want to reach our goals (which are servicing users, for all of us), to keep arguing over these things. We have to educate our users, and make our choices more user friendly.
I hope we can make leaps and bounds in the coming year, and make major improvements to the working relationships we're trying to repair.
Albert wrote on 09/12/10 at 4:32 pm :
Lucas, thanks for all your great work on Ruby and Debian. I've been using Ruby 1.9.1 on i386 and amd64 for awhile and have run into a slew of problems, but using these two technologies is still completely worth it to me. I think the Debian team does an awesome job of getting an incredibly diverse array of technologies to play nicely together. Similarly, the Ruby community does an awesome job of pushing the envelop with development techniques.
While lots of people complain about the line that Debian has drawn with regards to Ruby packaging, I think its perfectly justified and the right thing to do – its in the best interest of both Debian and Ruby because in the long run it will help reduce bugs and the amount of work needed to maintain the packages. I love developing in Ruby, but I'm disappointed Rubygems hasn't complied with Debian's policies. I completely side with Debian without hesitation.
Albert wrote on 09/12/10 at 4:40 pm :
Raggi posted that helpful comment while I was writing mine, and I agree his sentiment that Debian and Ruby have a bright future with lots of improvements coming within the next year.
Greg wrote on 09/12/10 at 5:01 pm :
It's sad that this has come to such a bad state. I'm not a Ruby developer, but I am a long time Debian user and now a Ubuntu user. I've worked as a Linux Admin in the hosting industry for some time, and Ruby has largely been a PITA.
I've never seen any software break itself so much between such trivial releases. Now, with that said, I also think the Rails framework for Ruby is awesome. I wish that there was a true equivalent of Rails for Python. Yeah, Django is close, but it's not the same.
Anyway, back to the topic at hand. If you give up maintaining Ruby for Debian then that will force everyone to install from source, which they already do (for the most part). What I don't get though is why the Ruby devs are so insistent on bleeding edge, especially in production environments? Are they content with their language and packages being more of a hobby language and framework, or do they actually hope to have it become something stable and usable in large production systems?
shermann wrote on 09/12/10 at 5:10 pm :
You are write about Ruby…it's really a mess.
Well, Puppet, one of my and other peoples main application written in Ruby needs it. I think Google (aka Andrew P. and Google Sysadmins) can sing a song about ruby and puppet.
As long as you are not using Gems everything is fine. And Puppet and Ruby right now is just a find experience, I even tend to code some Japanese^WRuby scripts, even I don't like that language.
I'm thinking about an alternative to Ruby for Puppet…but Chef or cfengine is not a solution, regaring the all mighty ness of Puppet.
I hope, Ruby Upstream Devs are thinking about their Userbase, to provide Stable Releases and Development releases like Python does. If not, it's a non winning case for Debian and all serious Distros which want to provide stable releases.
shermann wrote on 09/12/10 at 5:11 pm :
oh well, just s/write/right/ I'm tired so mistakes happen
Rodrigo Rosenfeld Rosas wrote on 09/12/10 at 5:17 pm :
Let me explain a bit this bleeding edge thing with Ruby. Lots of Ruby developers use Rails (I'm one of them).
Rails 3 has just been released and has a lot of great enhancements and it is faster with Ruby 1.9, but at the moment the only 1.9 supported release is 1.9.2. Ruby 1.9 has support for system threads while 1.8 has not and it is also much faster. Unicode support is also much better for Ruby 1.9.
Those are the reasons why Rails developer are on bleeding edge Ruby and Rails. They don't need to but they opt to because of the great advantages of being on the edge currently. Both Ruby and Rails have evolved a lot lately. Maybe some day we stop this edge thingy, but there is still lots of improvements on the way (on the Ruby side, there is still space for 'ação'.upcase become 'AÇÃO' instead of 'AçãO').
Greg wrote on 09/12/10 at 5:26 pm :
It's great that 1.9.2 is faster than the others. That doesn't make it production ready, and breaking any and all backwards capabilities isn't helpful either.
We can't expect Ruby to be inline with Debian as they have no relation to each other. However, Debian being what it is, it would be extremely helpful to a lot of people if there was more cooperation. I can't help but wonder if some of the issues on this stem from Ruby developers being more of a Mac breed and are clashing with the values of Linux users. ;)
Lucas wrote on 09/12/10 at 5:27 pm :
@raggi: On Ruby on embedded devices. I'm talking about the higher end of embedded devices, aka the ones who already run Linux. I'm happily running Ruby on both by Nokia N900 and my Linksys NSLU2. I think that it would be quite a failure of Ruby not to be able to be useful as-is on embedded devices, when other similar programming languages are. Sure, it might not be perfect performance-wise, but that's not a major problem.
One thing to remember about portability issues is that they are usually common to several architectures or systems (think of endianness, word size, POSIX compliance, etc), so fixing it once might fix it for several architectures or systems. It might have looked completely useless to make sure that Ruby worked on ARM or mips 5 years ago, but now that there are ARM-powered netbooks, it doesn't look ridiculous anymore, and all the work done on ARM while it looked useless can be re-used now to get Ruby working on such netbooks in a very short timeframe.
A debian-specific problem is that we support all our packages on all architectures (or at least, try to). So if Ruby doesn't work on one of the architectures, it might prevent many more applications to grow a dependency on Ruby. The fact that there are no so many applications written in Ruby in the wild might be related to the fact that Ruby is not very dependable. For example, the Debian infrastructure uses puppet, and the Debian sysadmins have gone through many issues on getting Ruby to work properly on Debian GNU/kFreeBSD. The root issue (identified by the Debian kFreebsd porters) was that the threading code was using sigprocmask(), which has undefined behaviour in threaded programs. (see http://redmine.ruby-lang.org/issues/show/3779)
Caring about portability is just a good way to improve code quality.
Lucas wrote on 09/12/10 at 5:31 pm :
@Greg: the fact that many Ruby developers have a web development background and not a UNIX background is clearly one of the reasons why it is harder to deal with that community than with the Perl or Python communities. And it is also true that many Ruby developers are using Mac OS X on their development systems, and don't feel very concerned by Linux distributions issues.
raggi wrote on 09/12/10 at 5:35 pm :
Lucas: I'm curious, do the 4mb segments not cause you pain for use in environments that only have limited ram?
Interesting issues under kFreeBSD, I've been using ruby on native FreeBSD for a long time and have come across similar issues before. Sadly there's no accounting for MRIs instabilities eh :-/
Absolutely agree with your sentiments about portability :-)
raggi wrote on 09/12/10 at 5:39 pm :
Lucas – a very large number of companies I know of deploy to ubuntu systems but use rvm or manual builds, I agree that most of the devs work on OSX, but to say that most don't care about the Linux side, I'm not so sure. Of course we both lack real numbers, so it's hard to say. I definitely think that the more recent builds will reduce peoples need for manual building, at least I can hope that. I'd also suggest that some of the historical issues actually account for part of the reason rvm receives such significant donations, despite being just a collection of sh scripts.
Lucas wrote on 09/12/10 at 5:57 pm :
@raggi: my use of ruby on such platforms is rather limited, but no, no problems seen.
Note that Debian GNU/kFreeBSD uses the freebsd kernel with the GNU libc, so it might not exhibit the same issues as stock FreeBSD.
Regarding large companies deploying Ruby using distribution packages vs rvm, there are companies on both sides. For example, I know from the investigation of http://redmine.ruby-lang.org/issues/show/2739 that Google is using puppet and the Ubuntu packages for Ruby internally. (I don't know the scale of the deployment, though. But the fact that they ran into this issue before everybody else makes me think that it's not too small).
sysadmin wrote on 09/12/10 at 6:29 pm :
For me most of rants from Ruby people (or Python, to a least extent) come from people that might be excellent developers but have no idea regarding system administration and best ingeneering practices (and I say "might be excellent developers" out of courtesy; I don't really think someone can be an excellent -even good, developer disregarding sysadmin and proper engineering practices).
Some examples:
* Not coping with distribution providers installing at /var/lib/ruby and forcing instead /usr/local. That's so obnoxius it hardly needs to be debated. Haven't they heard about FHS or proper developing practices so it's easy to "rebase" a deployment?
* Forcing "bleeding edge" to everybody. It's obvious they never needed to support installs on the hundreds (or even in the tens), but it's obvious they never heard about stability and QA. It's lame and backwards some 20~30 years that their idea of "support" is returning to the days where compiled apps needed to be statically linked to libraries (having to deploy almost every single app with their own bunch of packages it depends on because no one takes care of backward compatibility is just the same, with exactly the same problems about supportability than the static library environment).
* You told that current Ruby on Squeeze is out of a daily snapshot. Why??? May it be because no one from Ruby is in the position of saying "*This* is stable; *this* is going to be supported for the next X years and we guarantee *this* not to change API within those X years; only bug corrections will be produced and they'll be at the extraversion level"? Because this would be a rather serious "warning: lame project" indicator.
Lucas wrote on 09/12/10 at 6:37 pm :
@sysadmin: on Ruby in Squeeze. It is actually Ruby 1.9.X that is out of a daily snapshot. What happened is:
- we initially planned to release with Ruby 1.9.1.x
- the squeeze freeze was delayed
- a newer GCC was uploaded (minor release in the 4.4 branch)
- Ruby 1.9.1.x was failing to build with the newer GCC ( http://redmine.ruby-lang.org/issues/show/2727 ; hard to investigate because hard to reduce to a simple test case, still not fixed in 1.9.1.x)
- We decided to go with 1.9.2.x, since it was building fine
- During Debconf, I did the initial work on switching to 1.9.2, but 1.9.2 was not released yet at the time. So I used an SVN snapshot from a couple of weeks before the freeze.
Ruby 1.9.2 has now been released, and after some additional work, it got uploaded to Debian unstable today ( http://packages.qa.debian.org/r/ruby1.9.1/news/20100912T150314Z.html ). Now I just need the debian release team to accept it into squeeze (but I need to make sure it builds everywhere first).
Greg wrote on 09/12/10 at 6:40 pm :
If those points were ever met, Ruby, and more importantly, RoR would become dominating in the web market.
I still prefer Python to Ruby for sysadmin stuff, but as a web framework Rails adds so much to Ruby. Ruby could become the next PHP in terms of people jumping on the bandwagon. I think what largely holds it back is attitude. Aside from what we touched on already, you have tools for Ruby and Rails development such as Textmate that will stay OS X only because "that's how they like it".
Puppet is awesome, and I admit that I didn't get to use it as much as I wish I could have. Now that I'm no longer doing Linux Admin duties I'm focusing more on learning how to program, primarily in C++ and some C# at this time.
Anonymous wrote on 09/12/10 at 9:20 pm :
I prefer Debian provided packages any day. I don't want to start my (say) Rails installation with installing dev libraries and compiling. And compiling each time I need to add another gem. I want it just work. And it does for me.
// Just a Debian user.
Andrew Ferk wrote on 09/12/10 at 9:49 pm :
I have a question about the following statement:
"but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD"
Can you explain this in more detail? Thanks.
Thomas Koch wrote on 09/12/10 at 9:55 pm :
Hi Lucas,
your blog post is another item in my collection, why Ruby is rather the problem then the solution. If it could make your decision easier: You'd make me happy, if Ruby would be dropped from Debian.
If Ruby is not part of Debian, then it makes it much easier for everybody to keep it out of the company. – A sysadmin may be able to say, what's not in Debian won't be deployed!
Please don't take this personal, but there are not only friends of ruby.
Greg wrote on 09/12/10 at 9:58 pm :
Thomas, the problem is there are useful applications that are build on Ruby, namely Puppet. I'm not sure if you're aware of what Puppet is or does, but it's really a great tool to sysadmins. Yes, you could accomplish the same thing with home grown scripts and such, but it seems a waste to trash Puppet simply because the people who constantly develop Rails applications need the most bleeding edge.
spatulasnout wrote on 09/13/10 at 2:31 am :
I've been using Ruby since 1999 and Debian since 2004, and I'm grateful to the numerous volunteers who have made both projects a possibility and a reality.
Regarding someone calling Debian-specific changes unforgivable, I think it's fairly well known on the mailing lists that this person has a history of using bombastic and strident language. As such, I think it easiest to simply filter out this sort of noise when reading this person's posts.
Regarding: "The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources."
I think this is largely a problem of historical inertia, however regrettable. For instance, it would be completely false to suggest that the aforementioned hostility mysteriously appeared one day out of a vacuum. My belief is that the hostility reflects a perception that developed over the course of years of fielding questions from baffled users on ruby-talk, who didn't understand why their ruby installation on debian was missing half its standard library.
Please note that the purpose of my comments here are not to assign blame, and that I personally value both Debian and Ruby very highly.
Circa 2004, there was no apt-get install ruby-full. If one wanted a ruby installation on Debian that was the SIMPLE EQUIVALENT to ./configure && make && sudo make install, one needed to apt-get something like the following (and I'm not sure this is complete.)
libbigdecimal-ruby1.8 libcurses-ruby1.8 libdbm-ruby1.8 libdl-ruby1.8 libdrb-ruby1.8 liberb-ruby1.8 libgdbm-ruby1.8 libiconv-ruby1.8 libopenssl-ruby1.8 libpty-ruby1.8 libreadline-ruby1.8 librexml-ruby1.8 libruby1.8 libsdbm-ruby1.8 libsoap-ruby1.8 libstrscan-ruby1.8 libsyslog-ruby1.8 libtcltk-ruby1.8 libtest-unit-ruby1.8 libtk-ruby1.8 libwebrick-ruby1.8 libxmlrpc-ruby1.8 libyaml-ruby1.8 libzlib-ruby1.8 rdoc1.8 ri1.8 ruby1.8 ruby1.8-dev ruby1.8-elisp ruby1.8-examples
It was not uncommon at the time to read posts like the following, saying things like "Debian vs. Ruby is a Tale of Woe of epic proportions."
That person, in a fit of desperation, was resorting to the following:
for pkg in $(apt-cache search ruby | grep -E '^lib' | grep -v 'ruby1.6′ | awk '{print $1}' | wc -l); do echo "Installing $pkg…"; sudo apt-get –yes –force-yes install $pkg; done
Whereas many of us (myself included) simply advocated: ./configure –prefix=/opt && make …
We can't change the past. And I hope your Mythbusting FAQ will be helpful in alerting those who retain lingering hostility from the early days, that many of our negative perceptions about Ruby on Debian from that time may no longer reflect the present reality.
And once again, I'd like to thank all the volunteers who have made both Debian and Ruby possible.
postmodern wrote on 09/13/10 at 5:15 am :
The reason for the push towards Ruby 1.9.2, is it includes all the performance improvements of 1.9.1 and passes 99% of RubySpec. Ruby 1.9.1 did not pass all of RubySpec and had bugs; a couple of which segfaulted active-support 3.0.0 testing suite. This was why Rails3 explicitly dropped support for 1.9.1. Additionally, most people seem to be running 1.8.7, and if they were crazy enough to use 1.9.1 they will probably upgrade to 1.9.2 anyways.
Ruby 1.8.6 also got the axe (by Rails3) in favor of 1.8.7, since 1.8.6 had many bugs and performance problems. Ruby 1.8.7 also includes backported features from 1.9.1, as a means to transition developers into 1.9.x. Other projects (such as DataMapper) are following suit by dropping support for Ruby 1.8.6 and 1.9.1. (Did I mention that it's an utter pain to develop against 1.8.6?)
It was also announced by the ruby-core team that Ruby 1.8.8 will be the last version in the 1.8.x family, and will only contain bug-fixes. This means 1.8.x is reaching end-of-life, and that it's time to start porting any old code to 1.9.2. Porting to 1.9.2 is easy, assuming you have good test-coverage on your project or previously ported to 1.9.1.
For those who say RubyGems is "broken" or could be improved, please submit bugs or patches. RubyGems can always use further improvement/scrutiny.
(Why is rubygems still using rubyforge.org? They should be using the GitHub Issue tracker at http://github.com/rubygems/rubygems.)
Personally, I think a huge problem with RubyGems and installation are Ruby C extensions. C extensions have no (real) way of specifying dependencies on system libraries, but require a compiler and header files to compile against. Not to mention mkmf, which generates the Makefiles for C extensions, is some hideous Ruby code. That said, I'm a huge fan of Ruby FFI bindings, which require no compilation and are supported by all Ruby implementations.
I find it funny that Ruby is not officially supported for Debian/x86-64. I started using Ruby 1.8.6 on x86-64 back in 2005.
Yes, Ruby, RubyGems and Rails have made mistakes or put out bad releases in the past. It seems now that the Ruby community is working hard to improve the user/developer experience. As a result, we now have http://rubygems.org, http://rubydoc.info, RVM, memprof, Bundler, Rails3, Ruby 1.9.2 and RubySpec.
Oh, also, don't feed the trolls.
postmodern wrote on 09/13/10 at 7:34 am :
I should point out that "officially supported" is a somewhat misleading label used by ruby-lang.org. As I recall, ruby-core runs their current Continuous Integration server on Debian IA32. This is why ruby-lang.org states that Debian IA32 is "officially supported".
Applying their definition of "supported", Mac OSX 10.5 and 10.6 (the dominant OS amongst Rubyists) are not even supported.
There was also discussion in the last ruby-core meeting minutes of setting up a new Continue Integration server.
Also, I don't think many Rubyists endorse breaking APIs on minor versions. http://semver.org is very popular amongst Ruby project maintainers.
lucas wrote on 09/13/10 at 8:51 am :
@andrew: the Debian packages are automatically built on all supported architectures. The status page to follow the status is https://buildd.debian.org/pkg.cgi?pkg=ruby1.9.1.
The ruby1.9.1 package (for Ruby 1.9.2) currently enables the bootstrap testsuite, and consider its failure as fatal, and the full test suite, without considering its failure as fatal (because else, we wouldn't be able to ship it).
But there are currently test suite failures on several architectures, that seem to indicate that Ruby is broken on those architectures. There are open bugs for each of them: http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=ruby1.9.1
Looking at some failures and investigating them is a good way to help. it is possible that the sparc and kfreebsd failures are actually caused by the same issue. The ia64 one has apparently been fixed since the bug was filed (the test suite no longer segfaults).
Kurtis Rainbolt-Greene wrote on 09/13/10 at 10:37 am :
Perhaps there's a definition of "myth" I'm not aware of? Even the one that turns out to be not true is only not true quite recently, so it was very much true at the time people talked about it.
Robert Klemme wrote on 09/13/10 at 11:42 am :
Lucas, I'd like to thank you for your work on Debian (although I haven't benefited from it since I don't use Debian) and especially for raising awareness of these issues in a wider audience. I do agree that these packaging and compatibility issues need to be improved in order to get Ruby where many people believe it should be – in the same position that Perl and Python are today, i.e. first class choice for system administration scripting and application development.
In order to improve things we should take a brief look at the root causes of the current situation and see whether we can remedy them. To me it seems there are two major issues here:
1. Ruby versioning and compatibility. The switch from 1.8 to 1.9 was a major one – not because of the changed runtime system but because of the dramatic changes of the language which create incompatibilities. I'm afraid, 1.8.7 – which was intended to ease migration – probably made things harder because now there was the "real" 1.8 (meaning 1.8.6), the new 1.9.x and a hybrid version 1.8.7 between them.
2. Gem package management. Personally I was slow to adopt gems because having an independent package management did not feel right to me. At the time the Gem system was conceived mature package management systems for part of the operating systems that Ruby was used on were in place already. OTOH there are other operating systems which still do not have a package system like Debian's and Red Hat's (I am thinking "Windows" of course). I do believe the independent existence of Ruby Gem system is what causes most headaches for you as a maintainer of an OS with a proper package management system.
Item 1 cannot be easily changed because history is as it is. In hindsight it might have been better to call what has become 1.9.x "2.x" because of the language changes. I hope this is handled differently during future language changes.
Item 2 is probably also difficult as well but I would like to make a suggestion and hear what others think about this. I am pretty sure that this idea will earn quite a few spontaneous rejections but let's see. There are two main users of Gems: Gem authors and people who actually only use Gems. For the latter group (which is likely larger) the main advantage of Gems is that they can say "gem install foo" and have the "foo" gem installed on their system ready to work. I am pretty sure that these people do not care much about the underlying mechanics. So what about having a version of the "gem" command that uses the system's package manager to resolve dependencies and load other packages? The most dramatic difference will be that there is no user level package management as there is with the current Gem implementation. However, I am not sure that this is a bad thing per se.
Gem authors could certainly be helped by providing the appropriate tools to do the gem creation and packaging. An alternative would be to create a bridge between gem repository and the OS's package repository which would provide an automated or half automated migration of gems to the package system reducing the job of package maintainers to testing and selecting the proper version (which is still hard enough).
While I do think that this suggestion will create some efforts on several sides it might be a good remedy in the mit term: there would be no more second package management system on OS which do have their package management already, others could still work with the current Gem logic. And life would not become harder for Gem authors.
Clément wrote on 09/13/10 at 12:24 pm :
As a Rails developer, I never had any problem with ruby / rails on Ubuntu.
All is working just fine.
You're doing a great job, thanks for all.
Brian Candler wrote on 09/13/10 at 12:43 pm :
Preamble: I can only speak for my own experiences, not "the community". I am both a programmer and system administrator, although until recently most of my sysadmin experience was in *BSD systems and RPM-based Linux distros.
I 100% support the idea of keeping "stable" versions of software, and the major breakages between certain patch-level releases of 1.8.6 demonstrates why this is important. Ruby itself has let down its users badly here, by adding all sorts of kitchen-sink changes into what IMO should have been purely maintenance branches, and it falls to system packagers like Debian to fill that void.
However, I also completely understand and basically agree with the "unforgiveable" rant.
For me one of the great things about Ruby is its completeness. The source is about one third of the size of Perl, but you get a whole lot more standard functionality, like Net::HTTP and Net::HTTPS, out of the box.
So when I first installed the Ubuntu ruby package, and found lib/net/https.rb was completely missing, my knee-jerk reaction was "WTF?" It looked just like a packaging error.
After calming down, and considering that maybe there was a reason for this omission, I found the libopenssl-ruby package. There is logic behind it – https.rb wouldn't be very useful without openssl.so – but it was surprising to me, when other systems I had worked on didn't have this issue. (That is: "yum install ruby" was fine. "apt-get install ruby" wasn't)
The same applies to putting rubygems under /var. It gives the impression that Debian packagers "know better" than the original software author, and this comes across as arrogant. Put more mildly: I think Debian aims for consistency within a Debian system. So this decision supports POLS for Debian users who don't know Ruby, but it violates POLS for Ruby users who don't know Debian. The fact that /var/lib/gems/1.8/bin is not in $PATH is just a headache which you don't get on other systems.
As for disabling "gem update –system", this seems like OS policy overriding administrator policy, putting unnecessary obstables in the way. Look at this:
$ sudo gem install rails
ERROR: Error installing rails:
i18n requires RubyGems version >= 1.3.6
$ sudo gem update --system
ERROR: While executing gem ... (RuntimeError)
gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.
$ apt-cache show rubygems
Version: 1.3.5-1ubuntu2
I'd say that "throw away the Debian packages and install from source" is a legitimate answer to this one, when you have a job which needs to be done.
Now, I don't think you can dismiss any of these points as "myths" by pointing to some future, non-released version of Debian which fixes them. On the contrary: by doing so you are acknowledging that these are genuine problems with current releases, and you are also admitting that these are the result of bad decisions (because they will be reversed in future).
But I also understand you're in a position where it's hard to win. A Debian package has to support two distinct use cases: providing ruby support for other packaged applications which depend on it (e.g. puppet); and providing a package for ruby end-users, those who write and deploy their own apps in ruby.
I don't envy your job, but listening to your users' needs rather than dismissing them is important. I am glad to see that steps are finally being taken in that direction.
postmodern wrote on 09/13/10 at 1:09 pm :
@Brian I wish I could upvote your comment, well said. Additionally, I always disliked having to set the RUBYOPT env variable to auto-load rubygems. Debian kept rubygems separate from the ruby-1.9.1 package, after rubygems was explicitly merged into upstream ruby-stdlib so users wouldn't have to mess with RUBYOPT. I remember Gentoo would simply add
RUBYOPT="-rrubygems"to the system env.d files. I'm not sure if this too is an old Myth.
Per disabling
gem update --system, I would like to see a pluggable update system for RubyGems. This way Debian, RedHat, Arc, Gentoo, etc could override the updating of RubyGems, and have it call out to the system package manager.
Skade wrote on 09/13/10 at 2:14 pm :
I am one of the persons that is constantly put off by the problematic process to install Ruby on Debian. That said, the situation is constantly getting better. The ruby-full package did a lot in that area. But why is there no ruby19-full package? The 1.9 support in Debian feels like history repeating. Its not like Ruby 1.9 was released yesterday. I do understand that Debian does not push Ruby 1.9.2 to their repositories immediately (but calling it "not stable" might not be good as well). Also, the ruby-full description calls 1.8 "the current stable version" of ruby, which I think is up to Ruby Core to decide. They flag 1.9 as "the current stable".
But I also think that this is a heavy cultural clash between to strong-headed communities. The biggest problem is that the Ruby Ecosystem did a tremendous sprint during the last few years which makes it hard for (conservative) package maintainers to keep up. RubyGems might be a chore to the Debian maintainers, but it is a necessary one: libraries iterate and release fast and are superseded even faster, sometimes. Considering the average size and scope of a Ruby Library, this is understandable. We just need a system that can keep up with that speed – and this one is not apt-get.
But however, my biggest problem this year was the dash through all minor versions of RubyGems 1.3.x, with all kinds of libraries suddenly introducing dependencies to just-released versions of RubyGems. I can fully understand that Debian does not want to follow this development and think it was unwise of the Ruby Community to force that push in such a central library. I do hope that this situation will improve with RubyGems now being a part of Ruby.
bdigital wrote on 09/13/10 at 2:22 pm :
if the behavior of ruby gems is different from installing gems from source, or the default ruby package doesn't include libraries rails requires, it seems to me that many ruby developers will probably continue to avoid the debian ruby packages. Especially because of how horrendous the experience was "pre 2005," as you say.
Brian Candler wrote on 09/13/10 at 3:14 pm :
@postmodern: Thanks for your support.
Regarding gem update –system: IIUC, it does not "replace code from the Rubygems Debian package" as Lucas said, but just installs a newer version in /var/lib/gems/1.8/rubygems-update-x.x.x/
Of course, it is a potential source of confusion to sysadmins for dpkg to report version X of rubygems, where version Y is actually live. But IMO that should be a choice for the well-informed system administrator to make, and it comes across as arrogant for it to be forbidden.
After all, the reason I use gems instead of apt packages of ruby libraries is because Debian (quite rightly) won't keep up with the latest-and-greatest of these. By including rubygems, Debian is allowing people to install versions of many libraries which are different to those available in the apt repositories. So why shouldn't that right extend to rubygems itself?
Wayne E. Seguin wrote on 09/13/10 at 4:01 pm :
This is an excellent exposition and clarifies many common misconceptions with system Ruby packages in general. I firmly believe that all Ruby developers should read this post. One point I try to make is that system Ruby packages must not break any packages that depend on them, which is why it make sense that system packages will always have a very controlled release cycle. This is the correct way to do (system level) Ruby package management.
RVM enables users to be able to run any arbitrary Ruby environment isolated on a per-user (user level) basis so as to not disrupt the system Ruby. In other words, let system Ruby be system ruby, dedicated to and for the operation of the core OS while separately enabling arbitrary combinations of Rubies + Gems. This yields the best of both worlds, namely stable OS and specific customized application environments such that one does not impose requirements on the other. Thus it should be 'RVM with system Ruby' not 'RVM vs system Ruby'.
Lucas, it is very easy to get discouraged. You are doing the community a great service regardless of their realization of it. I also understand that it is not easy to let community comments just 'roll off', especially when they make generalized statements without obviously knowing all that is involved and backing their comments up with well thought out details :-p
Keep at it Lucas, you are doing a great job.
Klaus wrote on 09/13/10 at 4:10 pm :
I am using Ruby for around ten years and Debian even longer. I can understand the issues of debian-conform packaging for any environment providing its own package management (ruby, tex, R, whatever…). There always are issues.
I want to thank you a lot for your work. I like to have Debian Ruby packages where I dont have to care about security fixes on my own, where I even don't need compilers installed on my server etc.
So there are users outside who really appreciate what you are doing!
TheGZeus wrote on 09/13/10 at 4:54 pm :
I say drop support for architectures that they don't support.
Will non i386 ruby users be angry? Yes.
Will it be Debian's fault? No.
Isn't the policy to make sure it compiles for _supported_ architectures? They don't support it.
Let it die.
I've never been a fan of the language, and it seems that the community is poisonous.
Michael Schuerig wrote on 09/13/10 at 6:32 pm :
I've heard of it before, but still I'm rather surprised that so many people seem to be having problems with ruby on Debian.
I'm using this combination for more than five years now to do Rails development and it is just fine.
For my own development I'm using gems, not the packages, even where they are available. For my work, bleeding edge versions often are suitable or even necessary. First and foremost, however, I have to keep in sync with coworkers on other platforms.
I'm happily using packaged ruby libs where they are required by other packages that I'm using for their functionality and not because they're incidentally written in ruby.
As for gem'ed binaries being installed in /var/lib/gems/1.8/bin, is this really causing anyone trouble? If it does, I wonder whether these people are well-advised to install gems at all, if they're not able to add that directory to their path.
pronobgeek wrote on 09/13/10 at 7:40 pm :
Lucas, I really hope you don't quit your important work. As someone who came to Ruby from the Perl world, I am often amazed at the disarray of the ruby toolchain. I feel the problem is largely a cultural one and I think Ruby only improves when organizations like Debian insist on a bit more maturity than what we've seen from Ruby since it "hit the big time."
Obviously, you gotta do what's healthy for you… but if your demotivation is based on lack of appreciation from the community, I hope the myriad of supportive comments on this post demonstrate that your work is greatly appreciated by those who care about your goals. Someday Ruby will grow up, and when that day comes it's going to be because of the hard work of people like you.
Meneer R wrote on 09/14/10 at 3:25 am :
Hi Lucas,
Thank you for your effort and communication.
In general, when things are not what people expect, they tend to channel that frustration into hostility. That's a shame, but i am guilty of that as well.
As for Ruby. It's not so much that it's different from what people expect, but mainly because the only workaround people tend to know, is to just compile ruby & rubygems themselves.
The debian philosophy was always to have a very consistent platform and if that meant diverting packages from upstream, that so be it.
The developers working with ruby, the ones using for hosting say rails Applications, tend to care more about the consistency of the ruby platform, than the consistency of the debian platform.
Some of my team-mates work on OSX, some on Arch Linux, some on Ubuntu, some on Debian.
And like you pointed out, the ecosystem of Ruby is already quite fragmented. The complexity of also having debian specific versions just adds to the confusions.
And there isn't any clear documentation about how the debian ruby packages are different from upstream.
This creates the situation that repeating the same steps on one platform, does not have the same affect on another platform.
In the end, I would like to thank you for the efforts. But I would also like to state that, unless the packages are 100% upstream, with no diversions, we will always compile our own.
This is not just about choices about path locations. When you develop on one system and want to deploy on another system, i want to know that the development system has all the bugs that the deployment has.
So, even custom debian patches for crasher style bugs, are not really appreciated.
I understand that our priorities do not line up with those of debian. Why should debian care for any scenario other than developing on Debian release X and deploying on Debian release X?
So perhaps, the current situation (all the ruby/rails webdevs compiling upstream ruby+gems themselves) is the right way for the community to do this.
And the ruby packages in the repositories should focus on the packaged desktop and server applications that depenend on the ruby toolchain.
Because I think, that using a toolchain to run some other packaged application is just a very different use case from developping and deploying your own applications.
The only true proper debian way would be to create .deb packages of our websites and deploy them like that on the server.
Perhaps, and this is just a random suggestion, it's a good idea to have two sets of packages. A debian-ruby and an upstream-ruby. The upstream-ruby would be a garantueed 100% debian patch free version for web developers, whereas the debian-ruby package could be contain a patched ruby interpreter (without the gems tool) which is used by ruby desktop and server applications that are packaged in the repository.
Rusty wrote on 09/14/10 at 9:09 am :
I have found that pulling the packages for rubygems from the latest version of Debian into whatever version of Ubuntu I am using works great.
I think a lot of people don't realize this.
It also compounds when people have used both src and package installs of rubygems on the same machine. Even if one is removed it often results in (solvable) madness. :-)
Siv wrote on 09/14/10 at 10:19 am :
In the end, I really cannot see why do Ruby developers have to complain about Ruby and Rails in Debian/Ubuntu: it's like every other program: if you want to be always on the bleeding edge, then you have to compile and install applications from source; if you want stability, then you can use the provided packages.
If Rails wants to grow in Web sites usage more and more, then it has to avoid breaking API compatibility even between micro versions; a distribution must avoid breaking compatibility between updates, it is so obvious that there is no reason to complain at all. If I have a production site, then I don't want my site to crash after an update.
And about the number of packages: it is just the debian way; if I use Slackware, for example, I have only one package "kdelibs", if I use debian/ubuntu, then "kdelibs" is split into many many packages, so everyone can install only what is really necessary; if someone wants just everything, that's way metapackages exist.
Nigel Kersten wrote on 09/14/10 at 8:07 pm :
I'm one of the Google sysadmins responsible for our Puppet deployment here, and as there have been a few references to us, I thought I should speak up.
First, thank you Lucas for all your work. It's a difficult position to be in, and I'm happy to see so many people trying to be constructive about repairing the issues we're all facing.
I'm saddened to see how demotivated you've become, and we should all do a better job of helping out with debian-ruby.
We've never run an alternative Ruby stack for Puppet clients, and have always stuck with the Ubuntu packages.
For our servers we've spent time experimenting with Ruby Enterprise Edition, primarily due to the pthreads/rt_sigprocmask performance issue. When we were running Dapper server, the performance difference with Ruby EE vs the Ubuntu packages was astounding, and there was a clear win in going that way.
Once we'd migrated to Hardy we saw much less improvement, and decided to stick with the Ubuntu packages on the servers. This was mainly because we didn't want the management overhead of packaging up Ruby EE. Although they produce a deb, it's monolithic and installs into /usr/local, and I don't want to manage multiple stacks.
(John Leach/Brightbox are doing a good job of producing debs of Ruby EE that replace the system stack, which is a much more friendly way of distributing Ruby EE)
As we migrate to Lucid, we're facing this decision again, and I'm hoping things work out with squeeze/sid or maverick packages, as I'd much rather work with Debian/Ubuntu upstream than Ruby EE.
Brian Candler wrote on 09/14/10 at 10:20 pm :
Can I just correct something I wrote above.
" Regarding gem update –system: IIUC, it does not "replace code from the Rubygems Debian package" as Lucas said, but just installs a newer version in /var/lib/gems/1.8/rubygems-update-x.x.x/ "
Well, I just did a gem update –system on an Ubuntu Lucid box, by patching /usr/lib/ruby/1.8/rubygems/commands/update_command.rb (removing the 'fail' statement and inserting the original code which had been removed at that point)
This appeared to work, but then I ended up with gems being installed under /usr/lib/ruby/gems/1.8/gems, and the code for rubygems itself was installed in /usr/local/lib/site_ruby/1.8
I guess this demonstrates the real reason for Debian disabling the update mechanism: it's because if an update were installed, it would be missing Debian's mods.
So the sysadmin has two choices:
(1) go and find new .deb files for rubygems, rubygems1.8 and rubygems-doc, which eventually I got from http://gb.archive.ubuntu.com/ubuntu/pool/universe/libg/libgems-ruby/ – then rubygems works in the way Debian decided is best
(2) install rubygems from source, in which case rubygems works in the way its authors intended.
Noticias del Proyecto Debian – 21 de septiembre 2010 | Gustavo Pimentel's GNU/Linux Blog wrote on 09/21/10 at 8:41 pm :
[...] legendas sobre la manera que Ruby es empaquetado en Debian, Lucas Nussbaum, ha descripto en su blog ciertos mitos en torno a Ruby. Ello va desde la versión utilizada y la estabilidad de la API (la interfaz de programación), [...]
raorn wrote on 09/21/10 at 9:13 pm :
I just want to thank you, man. I maintain ruby for ALT Linux and I took some patches for redmine, packaging rails applications was easy. And I really liked you packaging policy (though I can't agree on everything).
I am doing this only for my personal fun, since tr00 rubysts doesn't give a sh*t about "packages" and "distributions". It's fun when you make several people happy with redmine or alexandria packages. It's fun when you can make several people happy with fixed bug (and in would be OK if upstream just silently ignore you).
Do what you have (and like) to do and ignore that herd of brain-damaged monkeys.
jack wrote on 09/22/10 at 10:55 pm :
The frustration is also felt on the python side of the fence see http://www.dzone.com/links/r/the_distros_have_killed_python.html
We need to find a solution for Python and Ruby (and lua etc.)
mathew wrote on 09/23/10 at 4:01 pm :
As a Ruby developer and Ubuntu and Debian user, and a system administrator with decades of experience, let me first say that the state of Ruby has improved greatly in recent Ubuntu releases, so thanks for that. But having said that, it's still not good enough. Just this week I had to rip out the packaged RubyGems and install the real one in order to install Gems successfully, as Brian Candler points out above. I also find it frustrating that I have to mess with symlinks to run 1.9.x as /usr/bin/ruby, but that's a minor issue.
The last time there was discussion between the Ruby developers and the Debian maintainers, the Ruby team were keen to work on a solution that would allow Debian to release packages that called RubyGems to update and maintain the Gems. That would have allowed Debian and Ubuntu to release packages for everything, shift the workload of fixing problems to the Ruby developers, and ensure that Ruby was kept up-to-date on Debian and Ubuntu.
Unfortunately, the attitude of the Debian maintainers was "No, we are not letting RubyGems install code, you do it how we say or else". At that point, I think most Ruby developers gave up on Debian, and decided they'd just have to download and compile in order to get a working Ruby on Debian. That's why you see that advice everywhere on the Internet. If you want to change that, you're going to need to accept that Debian as well as Ruby will need to make changes to how things are done. (While there are legitimate issues with C-based extensions, I still haven't heard any good reason why we couldn't fix the other 95% of Gems.)
The incompatibilities between Ruby versions are exaggerated, in my experience. I switched from 1.8 to 1.9 with very little breakage. The main issue was Unicode vs 'dumb bytes', which is hardly Ruby's fault. My main public library release (RSS and Atom syndication) worked fine once I had fixed that. My personal scripts all kept working too. Maybe there are some 'clever' code styles people used in 1.8 that have caused them grief in 1.9, but I haven't had a problem. I've got one production Rails app that's still running on Ruby 1.8, but that's because the app isn't offically supported on 1.9. (As far as I can tell from my own testing it works, it just isn't officially supported.)
You also need to distinguish between Ruby and Rails. They are very different communities. Rails developers are Mac-using bleeding-edge "throw it over the wall and let someone else shake the bugs out" types. Many of them don't believe in such absurd luxuries as API documentation. They tend towards cryptic code and wheel-reinvention. The core Ruby team are a completely different set of people, and are much more pragmatic. They do care about not breaking things and providing an orderly path from 1.8 to 1.9. As a Ruby guy, the Rails community exasperates me.
Maybe it would be an idea to set up a Google Group or similar discussion list, so people who would like to hash out these problems and come up with a solution can do so? Then the proposed solution could be taken to the Debian and Ruby teams for consideration.
Прикладная дебианавтика: Debian vs Ruby wrote on 10/7/10 at 11:17 am :
[...] vs Ruby Прочитал несколько постов на тему разногласий между [...]
Elijah wrote on 01/29/11 at 10:05 am :
I love debian, but mathew is right. In this case, I think debian is dead wrong.
The thing that I have never heard debian folks understand is that it is totally necessary to use gems because that is how you bind your code to a specific library.
It is pointless for debian developers to insult ruby programmers for how fast their APIs change or for incorrectly versioning their APIs. Even if every gem was 100% correctly versioned, the stark reality is that the technology that much ruby code is working with is changing really really fast. Debian, god bless it, is not going to be a viable ruby deploy environment unless it can learn to accommodate that reality better.
It is entirely normal for me to need different versions of a gem installed at any given time. Debian should not be in the business of deciding which one I should be using.
Adah Cordaro wrote on 05/5/11 at 6:31 pm :
I have been following your weblogs and individuals of other experts. Even now seeing which I'm not employing dark hat tacticts my site isn't ranking. Could you inform me if I have repetitive pages on a different site would that harm me? I use calendars and descriptions of over 140 tunes indicates and reproduce which on one of my other domains. Coulkd that hurt my page ranking?
Lynsey Gucciardo wrote on 05/5/11 at 6:31 pm :
Learned about it site from my friend. He pointed me right here and informed me I'd find which I necessity. He was correct! I got all the questions I had, answered. Didn't also consider long to find it. Adore the fact that you forced it so simple for individuals enjoy me. More power
Zinaware wrote on 08/5/11 at 8:30 pm :
Thanks fro the blog


text:
Bun B – The Pope
DJ Haze released a Trill O.G. leftover, "The Pope", on his newest mixtape.
DJ Haze released a Trill O.G. leftover, "The Pope", on his newest mixtape.
Another hot bonus track off Bun's Trill OG album, IN STORES NOW!
Bun B brings us some of that UGK sound and flow on this bonus track off Trill OG, which hit stores yesterday.
Hot new track from Bun off of Trill OG, which hits stores next Tuesday, produced by Steve Below.
Hot new track from Bun B off his upcoming album, Trill OG, which hits stores next Tuesday (8/3). Follow Bun on twitter @BunBTrillOG
Bun B grabs the hook master for his new track titled "Trillionaire". Unfortunately, I personally don't think T-Pain delivered on this one. Bun B's Trill O.G. hits stores August 3rd.
Hot new track from Bun B featuring Jeezy, off Bun's upcoming Trill OG album, in stores August 3rd.
The final version to Bun B's first leak off his upcoming Trill OG album is finally here. The beat has been slightly altered and is missing the previously mentioned verse from OJ Da Juiceman. Produced by dj b-do. Trill OG in stores August 3rd.
We heard the first snippet of this song on Bun B's No Mixtape that was released in February. Now Yo Gotti has contributed a verse to the track, which is also said to be the first single off Buns Trill OG album. Countin' Money should also see a feature from OJ Da Juiceman before all is said and done. Produced by DJ B-DO. Let us know what you think.
We heard Jeezy remix this classic song a few weeks ago and now one of the best to ever do it for Southern rap has remixed the track.
UGK's Bun B came extremely hard on this new track, letting us know why he's still the king of the Trill. Trill OG, Bun's long awaited third solo album, is slated to hit stores March 2. Long live the Pimp and UGK 4 Life!
Hot new song from the king of the Trill, featuring Ray J
May 11, 2009 | Houston based Rap-A-Lot records is gearing up for a big summer with releases from Z-Ro, Bun B and the late Pimp C.
April 2, 2009 | Bun B is the only member left of UGK, leaving him responsible to maintain the legacy of the group and his fallen partner, Pimp C.

subset: commoncrawl


text:
August 2, 2015
AURORA, Colo. -- The Denver suburb of Aurora is the site of another multiple shooting.
A gunman barricaded inside his home fired shots at police from a second-story window early today before he was killed as SWAT officers stormed the home. Police say they found the bodies of two other men and a woman when they entered the house.
It's believed the four knew each other.
Police say the suspect kept officers at bay for nearly six hours after neighbors reported gunfire at 3 a.m. inside the modest townhome.
It isn't known if officers shot the suspect or if he shot himself.
The shootings occurred about four miles southeast of the Aurora Mall, where 12 people were killed and dozens were wounded by a gunman at a midnight showing of "The Dark Knight Rises" on July 20. The man charged in that shooting, James Holmes, goes to court Monday for a preliminary hearing in which prosecutors will present their case against him.
To comment, the following rules must be followed:
Comments may be monitored for inappropriate content, but the station is under no legal obligation to do so.
If you believe a comment violates the above rules, please use the Flagging Tool to alert a Moderator.
Flagging does not guarantee removal.
Multiple violations may result in account suspension.
Decisions to suspend or unsuspend accounts are made by Station Moderators.
Questions may be sent to firstname.lastname@example.com. Please provide detailed information.
Click Here to access the online Public Inspection File
Viewers with disabilities can get assistance accessing this station's FCC Public Inspection File by contacting the station with the information listed below. Questions or concerns relating to the accessibility of the FCC's online public file system should be directed to the FCC at 888-225-5322, 888-835-5322 (TTY), or firstname.lastname@example.com.


text:
It brings you all the Hex Codes for the War Commander game.
War Commander Hex Codes is a free ... the Hex Codes for the War Commander game
This PC based software enables rapid demonstration and testing of VFD modules.
pick selected commands to run ... and Export Hex code
It can be used to calculate mathematical expressions of unlimited length.
Command Line Calculator ... , binary numbers, hex numbers, date ... with plot command. In the
Grab your spear and hoplon and march along with Greek Wars.
battles Greek Wars uses ... This provides a hex based, ... more realistic Command and Control
A fun and beautiful game from indie developers Spyn Doctor Games.
have been hexed into it ... under the command of Doodlelous


text:
Connect with Us
Now Playing
Loading stream...
Podcasts & RSS Feeds
|All Content
|View all podcasts & RSS feeds
Around the Nation
5:50 am
Mon January 23, 2012
Chicago Judge Illustrates His Rulings With Photos
By editor
Court opinions are usually not that exciting but a judge in Chicago is trying to liven up his rulings with illustrations. In one, he used an iconic photo of Bob Marley. The case was about a prisoner's right to keep his dreadlocks on religious grounds.


text:
Sign up now! Subscribe to the daily C-SPAN Alert and receive the latest on C-SPAN scheduling, trivia, special guests and programming announcements, and unique C-SPAN promotions.
Also sign up for our two other weekly alerts for Book TV and American History TV. Get information on each weekend's 48 hours of programming on C-SPAN2 and C-SPAN3.


text:
Mountain Mist Outdoor Center
Membership to the Meriden YMCA's Mountain Mist Outdoor Center is included in full adult, household, single parent household, senior adult, and senior household memberships.
Our beautiful 60 acre facility located at 576 High Hill Road is a great place to relax with your family or to hold a school, corporate,or other group outing. It's a great place to have a party or even a wedding. Our Outdoor Center includes a climbing tower, climbing walls, and ropes course which is great for birthday parties, or team building for school and company outings.
- 60 acres of property
- Outdoor pool with shallow bay and deep bay for open swim
- Adult lap swim available
- Fenced in sandbox play area
- Picnic areas
- Two playscapes
- Sand volleyball court
- Outdoor basketball and tennis courts
- Horseshoe pits
- Miles of hiking trails
- Soccer and softball fields
Days & Hours of Operation
- Monday - Friday: 2:00 p.m. - 8:00 p.m.
- Weekends: Saturday 10:00 a.m. - 8:00 p.m., Sunday 12:00 p.m. - 8:00 p.m.
- Open: Memorial Day to Labor Day (Weekends only until camp starts then every day through Labor Day)
- For Rentals: Contact Steve Markoja at 203.235.6386 x17.
Meriden YMCA Mountain Mist Outdoor Center Rules
- This facility is for Meriden YMCA full members (those with full privilege family, senior, or adult membership) and their guests.
- Meriden YMCA Members must present their membership card.
- Guest policy: The guest fee is $10 per person per day. You must be with a full Meriden YMCA member with a valid membership. There is a maximum of 5 guests per member. Guests must show photo id and sign in.
- All members and guests must follow pool rules and the Meriden YMCA Code of Conduct.
- The Meriden YMCA reserves the right to limit guest pass sales.
Directions: Please note not all GPS directions are accurate and may send you to High Hill Road in Wallingford which does not connect through to High Hill Road in Meriden. For correct directions Click here.
Contact the Meriden YMCA Today ›


text:
Let new car tax system begin
At the end of January, Durham County had collected the vast majority of real property taxes residents owed to provide the services we expect from our local government.
With seven months of the fiscal year gone – and the deadline for paying without penalty past – 96 percent of taxpayers had anted up for their real property tax bill. That's typical of recent years, perhaps a bit better than some.
But the vehicle tax is another story altogether. Barely seven in 10 of those bills have been paid. And that number, at this point in the fiscal year, has been gradually ticking down in recent years.
The General Assembly eight years ago came up with a solution to that collection struggle. It mandated that vehicle registration and vehicle taxes would be linked. No tax payment – no registration renewal.
But as so often happens, the details proved a bit peskier than the General Assembly might have imagined. The Department of Motor Vehicles and the Department of Revenue won permission to delay the launch until they could upgrade and integrate their computer systems to handle the new regulations.
Flash forward to this year, and two things are happening.
The computer systems are running smoothly and the linked payment system is set to go into effect in July.
Finally, you might think.
Not so fast.
Some state representatives from relatively small counties have introduced legislation to reverse the earlier law and de-link the tax and registration payments.
That's wrong on two counts.
Philosophically, it undoes a sensible system for helping county governments collect revenue that's owed them and that is now hard to collect – even in aggressive counties like Durham were the collection process for property taxes is quite successful.
On a practical level, it's rendering pointless the time-consuming and expensive task of setting up the system to enable the combined collections. As The Herald-Sun's Ray Gronberg reports today, the county's chief lobbyist told County Commissioners last week that the state has poured "several million" dollars into the new systems, and will have to pay up regardless of whether they are used.
"Citizens are ready for this to take place," county tax administrator Kim Simpson said. "And it's a smart thing for local and state government to work together for it to occur."
Yes, it is. The General Assembly should let well enough alone and let the system go into service in July.


text:
- User Name: Camichan19
- Member Since: Friday, September 28, 2012, 9:35 PM
- Name: Camille
- Location: Portland, OR
- Last Login: 2015-07-27 12:52:10
- Forum Info: Profile Posts (110)
- Usefulness: 106 with
1 opinions
[average 119.8 of 231073 opinions; standard deviation 432.8 ]
- Profile: Eh well, not much to say here. I've been editing (or learning to) since I was about 15, I really enjoy it, and try to bring as much feeling into my AMVs as possible. You probably won't find many here at the moment, since I'm trying to improve and strictly upload videos that I feel are "worthy" to be watched.
Thanks for stopping by!~


text:
Southern Highlands
Family day out to Bowral
The International Cricket Hall of Fame in Bowral is a great day out for the whole family. Open every day from 10.00 am to 5.00 pm, this interactive, fun-packed museum is just a short walk from Bowral Station and has shady picnic spots, an oval and a great cafe.
Must Do
Family day trips from Sydney
For $2.50 per person, your family can enjoy a fun day out with unlimited travel on Sydney's buses, trains, ferries and light rail every Sunday. The Southern Highlands is within easy reach of Sydney on the Family Funday ticket - from Central Station to Mittagong is a leisurely two-hour trip. Other stations are at Bowral, Moss Vale, Exeter and Bundanoon. Take your time to explore any of these towns on foot or by bus. You'll find good cafes, museums, pretty gardens, book shops and playgrounds.
A Family Funday Sunday pass also takes you to the Australian Botanic Garden Mount Annan, Australia's largest native, botanic garden. Trains leave Sydney Central every 30 minutes and take about an hour to Campbelltown Railway Station. Use your Funday Sunday ticket to travel by bus (with Busways) from the station to Mount Annan.


text:
The U.S. and Latin America
To the Editor:
I was surprised by the tone of Mark Falcoff's review of Hidden Terrors, my book about torture in Latin America [Books in Review, November 1978], until he disclosed that he had published an essay two years ago that touched on the same subject. Looking up his earlier piece, I found that it had been written in much the same style, relying in that instance on considerable facetiousness. For example, in discussing a Uruguayan police officer who revealed U.S. involvement in torture in Uruguay, Mr. Falcoff wrote: "We have no way of knowing whether the good commissioner winked at the newsman when he said this, or whether the latter wrote up the matter tongue in cheek."
From my book, Mr. Falcoff now has a way of knowing that the Uruguayan paid for his candor with his job and that Artur Aymoré, the Brazilian reporter from Jornal do Brasil to whom he spoke, was first interrogated at length by the Uruguayan police and then deported from Montevideo. Later, when Aymoré was back in Rio de Janeiro, an official from the U.S. Embassy tried to get him fired from his newspaper. Not everyone took the episode as lightly as Mr. Falcoff.
At another point, he noted parenthetically about the men who supply information concerning torture, "What a passion for anonymity these men have!" I, too, wish that conditions in Latin America were such that the men informed about torture and its practitioners could speak out publicly without reprisals. This is not the case.
Mr. Falcoff says that he found the descriptions of torture in my book "unsettling." Good. Perhaps he is coming to understand that real pain has been inflicted in Latin America and real blood has been shed.
I believe my book posed two central questions. Did the United States government play a critical role in overthrowing democracy in Brazil in 1964? Has the United States government contributed substantially to the rise in torture throughout Latin America? I think the readers of COMMENTARY, not already committed as is Mr. Falcoff to deriding the latter proposition, will examine the evidence and conclude that the answer to both questions is yes.
A. J. Langguth
New York City
Mark Falcoff writes:
If he will carefully read my review once again, A. J. Langguth will see that I did not fail to grasp the two points he wished to make in his book. However, I found his claims unjustified by the evidence which he presented. Since I quoted a wealth of examples, chapter and verse, I see no point in repeating myself here. I should, however, like to make one additional comment.
Hidden Terrors contains a number of claims which are substantially correct, some of which might be true (but are difficult to prove), many others which probably are not true, still others which assuredly are false. Yet all are treated as if they possessed equal validity, regardless of the source (or, as I pointed out, lack of it, on occasion), as long as they seem to underpin the author's thesis. Mr. Langguth has every right to disagree with my own views, but he should look to securing reliable evidence for his own, all the more so since his book is subtitled "The Truth about U.S. Police Operations in Latin America."
I concede that Mr. Langguth's response to my review is understandable. For ten years now, he and people like him have been able to anticipate uncritical acceptance of their fantasies on the part of a wider public because people with specialized knowledge of the areas about which they write have not bothered to respond. Unfortunately for them, that halcyon period is drawing to a close.


text:
A system for dispensing an adhesive comprises a first dispenser, a second dispenser, and a conduit. The first dispenser contains an adhesive. The second dispenser comprises a fluid. The first dispenser and second dispenser are each in fluid communication with the conduit. The conduit has an opening. One or both of the first dispenser or the second dispenser is operable to dispense adhesive or fluid through the opening of the conduit. The system may be used to apply adhesive to the tissue of a patient in a precise and controlled manner.
1. A method of applying an adhesive to the tissue of a patient during a surgical procedure, the method comprising:
(a) providing an adhesive dispensing system, wherein the adhesive dispensing system comprises:
(i) a first dispenser containing a biosurgical adhesive, wherein the adhesive comprises one of cyanoacrylate or isocyanate;
(ii) a second dispenser containing a fluid immiscible with said adhesive, said fluid comprising a drug, sclerosing agent, necrosing agent, coagulant, ablation agent, image enhancing agents, sealants, radiopharmaceutical, or combinations thereof, wherein said fluid is of a different color than said biosurgical adhesive;
(iii) a conduit comprising a substantially transparent, flexible tube, wherein each of the first dispenser and the second dispenser is in fluid communication with the conduit, wherein the conduit comprises an opening, wherein the one or both of the first dispenser or second dispenser is operable to dispense adhesive or fluid through the opening of the conduit;
(b) using the first dispenser to dispense an amount of adhesive into the conduit;
(c) using the second dispenser to dispense an amount of fluid into the conduit, wherein the dispensed fluid is urged against the dispensed adhesive;
(d) using the dispensed fluid to urge the dispensed adhesive through the conduit; and
(e) applying the dispensed adhesive to the tissue of the patient during the surgical procedure.
Biosurgical adhesives have been used in a variety of ways in various medical procedures. An exemplary adhesive is disclosed in U.S. Pub. No. 2004/0190975, the disclosure of which is incorporated by reference herein. Similarly, a variety of devices and techniques have been used to deliver adhesives at various sites. While several systems and methods have been made and used for delivering adhesives, it is believed that no one prior to the inventors has made or used the invention described in the appended claims.
While the specification concludes with claims which particularly point out and distinctly claim the invention, it is believed the present invention will be better understood from the following description of certain examples taken in conjunction with the accompanying drawings, in which like reference numerals identify the same elements and in which:
The following description of certain examples of the invention should not be used to limit the scope of the present invention. Other examples, features, aspects, embodiments, and advantages of the invention will become apparent to those skilled in the art from the following description, which is by way of illustration, one of the best modes contemplated for carrying out the invention. As will be realized, the invention is capable of other different and obvious aspects, all without departing from the invention. Accordingly, the drawings and descriptions should be regarded as illustrative in nature and not restrictive.
As shown in
Syringes (20, 30) each comprise a respective barrel (22, 32) and plunger (24, 34). In the present example, each of syringes (20, 30) comprises a standard commercially available syringe, without a needle attached, though any suitable alternatives may be used. As shown, each syringe (20, 30) is coupled with junction member (40), and each syringe (20, 30) is further in fluid communication with junction member (40). As will be described in greater detail below, in an exemplary use of adhesive delivery system (10), barrel (22) of first syringe (20) contains an adhesive material; while barrel (32) of second syringe (30) contains a fluid (72). While syringes (20, 30) are described herein as being used to dispense an adhesive material and a fluid, it is contemplated that a variety of alternative structures and devices may be used to dispense either or both of an adhesive material and a fluid.
Junction member (40) of the present example comprises a first channel (42), which is in fluid communication with a second channel (44). In one embodiment, first and second channels (42, 44) each comprise a leur lock type of feature (not shown), each of which are configured to mate with complimentary leur lock features (not shown) of first and second syringes (20, 30). Alternatively, any other suitable interface between syringes (20, 30) and conduits (42, 44) may be used. First and second channels (42, 44) form a generally "V"-like configuration in the present example. However, it will be appreciated that first and second channels (42, 44) may have any other suitable configuration (e.g., "T"-shaped, etc.). As is also shown, a web (46) is provided between first and second channels (42, 44). In this example, web (46) is substantially rigid, though web (46) may have other properties. It will also be appreciated that web (46) is optional, and that any suitable alternative may be used, and/or that web (46) may be omitted altogether.
Proximal end (52) of tube (50) is secured to second channel (44), distal of the junction of first and second channels (42, 44), and tube (50) is further in fluid communication with second channel (44). Tube (50) comprises a flexible, transparent material in the present example, though it will be appreciated that tube (50) may have any other suitable properties. Tip (60) is secured to distal end (54) of tube (50), and is further in fluid communication with tube (50). As shown in
The adhesive delivery system (10) of the present example is configured to deliver an adhesive through tip (60) via actuation of plungers (24, 34) of syringes (20, 30). An exemplary use is shown in
As is shown in
It will be appreciated that each adhesive plug (70) may be created by a user actuating plunger (24) to introduce adhesive material residing in barrel (22) to junction member (40) and/or tube (50). When a desired quantity of adhesive material has been so introduced, the user may stop actuating plunger (24) and may start actuating plunger (34) to distally force fluid (72) behind the adhesive material, thereby separating an adhesive plug (70) portion from the remainder of adhesive material within first channel (40). It will therefore be appreciated that adhesive plugs (70) may be provided in any size/amount desired by the user as a function of plunger (24, 34) manipulation. Adhesive plugs (70) may also be introduced at any point along the stream of fluid (72).
As noted above, fluid (72) of the present example comprises a sterile water or saline. However, suitable alternatives for fluid (72) may include any media that is immiscible with adhesive plug (70) (e.g., liquid, air, gel, etc.), and may comprise any suitable drug, sclerosing agent, necrosing agent, coagulant, ablation agent, image enhancing agents such as ultrasound, CT, MRI, PET, X-Ray (radiographic), sealants, or radiopharmaceutical. Other suitable alternatives for fluid (72) will be apparent to those of ordinary skill in the alt. It will also be appreciated that fluid (72) may comprise more than one type of fluid and/or material. Similarly, adhesive plug (70) may be substituted with any suitable fluid and/or material, including but not limited to the above-listed alternatives for fluid (72).
In one exemplary use, adhesive delivery system (10) is used to deliver tissue glue, which is provided by adhesive plug (70), in measured quantities. For instance, adhesive delivery system (10) may be used to adhere portions of tissue of a patient together. However, adhesive delivery system (10) may be used in a variety of other procedures and/or to deliver a variety of materials other than adhesive plugs (70). Suitable alternative uses for adhesive delivery system (10) will be apparent to those of ordinary skill in the art.
It will be appreciated that either or both of syringes (20, 30) may be selectively coupled with junction member (40), such that either or both of syringes (20, 30) may be removed from junction member (40) during a procedure of applying adhesive. For instance, syringe (20) may be used initially to provide an adhesive plug (70), and may then be removed from junction member (40). A replacement syringe (not shown) containing some other substance (e.g., an initiator, curing agent, a different adhesive, etc.) may then be selectively coupled with first channel (42). Such a replacement syringe could then be used to introduce the other substance to tube (50) behind a suitable amount of fluid (72). The other substance may then be advanced through tube (50) using additional fluid (72). Other suitable substances that may be introduced to tube (50) by either syringe (20, 30) will be apparent to those of ordinary skill in the art; as will other uses for embodiments described herein, structural variations of embodiments described herein, and substitutes and variations of components described herein.
Embodiments of the present invention have application in conventional endoscopic and open surgical instrumentation as well as application in robotic-assisted surgery.
Embodiments of the devices disclosed herein can be designed to be disposed of after a single use, or they can be designed to be used multiple times. Embodiments may, in either or both cases, be reconditioned for reuse after at least one use. Reconditioning may include any combination of the steps of disassembly of the device, followed by cleaning or replacement of particular pieces, and subsequent reassembly. In particular, embodiments of the device may be disassembled, and any number of the particular pieces or parts of the device may be selectively replaced or removed in any combination. Upon cleaning and/or replacement of particular parts, embodiments of the device may be reassembled for subsequent use either at a reconditioning facility, or by a surgical team immediately prior to a surgical procedure. Those skilled in the art will appreciate that reconditioning of a device may utilize a variety of techniques for disassembly, cleaning/replacement, and reassembly. Use of such techniques, and the resulting reconditioned device, are all within the scope of the present application.
By way of example only, embodiments described herein may be processed before surgery. First, a new or used instrument may be obtained and if necessary cleaned. The instrument may then be sterilized. In one sterilization technique, the instrument is placed in a closed an sealed container, such as a plastic or TYVEK bag. The container and instrument may then be placed in a field of radiation that can penetrate the container, such as gamma radiation, x-rays, or high-energy electrons. The radiation may kill bacteria on the instrument and in the container. The sterilized instrument may then be stored in the sterile container. the sealed container may keep the instrument sterile until it is opened in a medical facility. A device may also be sterilized using any other technique known in the art, including but not limited to beta or gamma radiation, ethylene oxide, or steam.
Having shown and described various embodiments of the present invention, further adaptations of the methods and systems described herein may be accomplished by appropriate modifications by one of ordinary skill in the art without departing from the scope of the present invention. Several of such potential modifications have been mentioned, and others will be apparent to those skilled in the art. For instance, the examples, embodiments, geometrics, materials, dimensions, ratios, steps, and the like discussed above are illustrative and are not required. Accordingly, the scope of the present invention should be considered in terms of the following claims and is understood not to be limited to the details of structure and operation shown and described in the specification and drawings.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Hold down Control (PC) or Command (Mac) key + mouseclick to select more than one option
|Avg. Dinner Entrée
|Greater than $25
|$18.01 - $25
|$12.01 - $18
|$7.01 - $12
|Less than $7
Posted by anonymous on 02/05/2010
Sandwiches are standard deli fare, but checkout staff is cold, and aloof...they haven't figured out that its the customers that keep them in employed. Well count me as one less. Fuzzy math always ends up in confusingly higher price than you'd expect. And a $.99 bag of chips costs $1.50 plus tax! ha!
Posted by Law Grad on 04/04/2009
Subs has done a good job in bringing in new quality items on their shelves to go along with the good food. I like the better chocolates and snacks. The variety is exstensive and different in the area. The new menus are great and easier to read. It is a shame that their other store on Broadway at 109th closed but the original Subsconscious seems to have improved in all areas. I am going to miss this place once I am done with school because it is hard to find places that are good, quick, and have a big variety not only for food but on the shelves also.
Posted by Anonymous on 11/29/2008
As a lot of other reviewers have stated the food, when it finally arrives, is typically quite good for takeout. The problem is the speed at which it arrives and the fact that it is almost never the correct order. Our household always has a little joke bet when we order about which of our orders will be the one that is messed up. The management of this place really needs to get a hold of their counter staff and give them some training or just can them. If you are ever feeling really good about yourself just call here and after a few brief moments talking to the person who answers the phone and you'll be brought right back down to earth.
Posted by Anonymous on 08/10/2008
Subsconcious has some great sandwiches and the food is pretty good. However, in the dozen or so times I've ordered online or by phone, they have NEVER gotten my order right. For example, I order a philly cheese steak with no lettuce or tomato and they add extra lettuce and tomato! And forget the cheese! Even when I go in there to order, I have to pay attention to make sure they get it right. In addition, they're often out of products that are on their menu and have to call back and offer a substitute. Finally, their delivery is usually speedy but sometimes it takes 1-2 hours to get a sandwich delivered 5 short blocks from the place. All in all, it just isn't worth it.
Posted by former customer on 08/05/2008
like one of the prior reviewers i have given subs-c chance after chance. but today it was soooo bad that i am finally able to say no more. the service on the phone is always rude and many innacuracies flow from that. When the food does come there is always something missing or not as you ordered. What should be hot is often cold, what should be cold is often hot. They've scraped by for so long, like many spots in our neighborhood, just because options were limited. well things have changed and many better options now exist, so subs-c better up their game and fast or they'll be done. i wanted to like it and each bad experience was always just below the threshold that would make you stop ordering from them... until today. so, thanks i guess for being so bad that you helped me quit you...
Posted by Live above Subs on 03/16/2008
The place is clean and the food isn't too bad.
Posted by Anonymous on 02/13/2008
The food is decent but for the last 4 times that I have ordered they have gotten the order wrong or taken over and hour to deliver