lnguyen

Don't forget IBM. (Not that they might seem any better than Oracle...)

They own a large chunk of the enterprise Java space with WebSphere. And they're also are a large driving force for Eclipse (was also their original code).

Sometimes there's a limit to how simple something can be. And sometimes you don't want to/shouldn't hide the complications.

I think that introducing users to ACLs, permissions and security is appropriate at this step. You can have a script/process in place that can take care of this but you should explain what's going on and why. Because if there's a security issue, they can at least have some kind idea of what happened.

Don't expect someone to do something that goes against their self-interest. Especially if they can do a song and dance and make people forget that nothing is getting done.

Go develop your app and sell it on the Cydia App Store.

It's possible and Apple is clearly allowing it to exist. That doesn't mean Apple has to make it easy for you to switch over to it or support it in any way.

Nitpick: It's not that they're eliminating the "travel middleman" but that they're removing removing unnecessary layers and being a better "middleman" by lowering costs for the consumer.

At it's core, Eclipse is really good at Java. It's why it killed off Visual Cafe and most other commercial IDEs (was sad to see Borland go).

The issue is that it's more than just a Java language editor. Once you load it up with all the extras to accommodate development models, frameworks, runtimes, build processes, etc. it does become an unwieldy mess. But it's really hard not to considering how moving parts large-scale development has.

An important lesson to learn in dealing with enterprise is to make sure the decision makers are happy. They have to feel they're being taken care of and are in control.

Trying to win on purely technical merits won't work. Being unresponsive especially during an evaluation is the kiss of death.

You'd be surprised how big a small company can appear. And it's really all about appearances more than reality.

I worked for a smaller outfit that sold to enterprise sometimes directly and sometimes through larger partners (CA primarily). Except when we told them they had no idea of our size.

There's Thomas (http://thomas.loc.gov/home/thomas.php). Bill text is available in PDF, XML and a printer-friendly HTML.

The question is how up-to-date the bill texts are. I doubt it can tracks in real time with changes/amendments voted on, etc. but then again any system bolted on the process as opposed to being fundamentally integrated into the process wouldn't be.

I'm inclined to believe that they agree to disagree.

Linus' use case for a pull request would probably be to much for a popularized and casual use case that is likely typical for GitHub.

And anyway it's Linus' prerogative to dictate his requirements for contributing to his project. The description he gives doesn't make it seem overly difficult (use what's already built-in).

When a diff tool is included with the scm, it's hard for the average user to separate the functionality even if it's possible.

And odds are you'll probably to be able to use different diff/merge tools to handle various file formats (plain text, xml, binary, etc.) so you won't have to rely on just one getting everything right.

The issue is that unless you have standards such as directory locations and structure, users and permissions, there isn't a way to automate the process of code deployment even with chef/puppet.

PaaS works because the provider has a standard and forces you to follow them. I don't mean that in any negative sense. I was in SCM for a number of years and know that kind of enforcement is necessary if you want to have any kind of repeatable, automatable and supportable deployments.

It's because I didn't want to mix in the Chef gems and dependencies with the system Ruby. I ran into some conflicts when I was initially building and testing so decided to eliminate the issue entirely.

With apt-get and yum you're installing pre-built binaries. This works well if that's all you need to do and are okay with the versions that are installed (typically not the latest unless it's a new distribution).

Once you start having to download and build source for apps/libraries that aren't pre-packaged you can run into issues about version compatibilities, where files are located, do you need to download additional packages (*-dev), etc. Having a service that takes care of this for you solves a lot of headaches (part of why rayburst got built in the first place).

It is a bit similar in concept to Gentoo but adds in a configuration management (CM) part. The current iteration doesn't take full advantage of the CM capabilities but we're working on it.

As far as building packages as compared to installed the distribution binaries... I've run into issues where the binary package wasn't compatible with libraries and apps that I had to install outside of apt-get or yum. For instance setting up reasonably modern Rails configuration with all the gems I needed on a Ubuntu 10.04 server.

I've also done builds and software configuration management for a living so the whole process is more like second nature at this point.

What you do want to avoid is a constant cycle of having to upgrade and build existing and working environments just to have the latest versions. At that point you do need to step back and evaluate if it's really necessary (security, fix, etc.).

You can just run the wget command by itself and save the script to a file

  wget -q -O rb.sh 'https://rayburst.com/i/[server id]'

Then take a look directly at the rb.sh

At that point you can do either

  chmod +x rb.sh
  ./rb.sh

or

  bash rb.sh

to run the saved script

I've checked the site on my MBP which is still running Snow Leopard and couldn't replicated what you were describing. (Although Safari does seem a bit slower than Chrome...)

Could you try it again?

The centmin.sh script is designed specifically for that install: CentOS + Nginx, MySQL, PHP. If it works well for you and that's what you need, then definitely keep using it.

rayburst sets up a framework to allow for more customized installs. You can pick the various apps and services and the modularity of the build scripts/recipes handles the install of the configuration. Part of what takes place is figuring out the build dependencies (ex Rails depends on Ruby) which would otherwise have to be hardcoded in a bash script.

I use chef as my behind-the-scenes mechanism for managing the installs. The client is a Ruby application so I build it as a runtime dependency.

I don't use rely on the distribution Ruby because of possible conflicts with gems that would have to get installed. The goal is to be able to get everything installed and then get out of the way.

The main issue is whether or not ubuntu is offered.

It looks like Linode does offer ubuntu 10.04 and 12.04 so you should be able to use rayburst for your installs.

I'll add them to the list on the next site update.

So far 12.04 LTS tests out without any need for updates (no build issues or service startup errors reported)

I'm not inclined to exposing them directly as the recipes rayburst uses are custom and not open source or redistributable.

"Dev Ops" isn't really something you choose to call yourself. You end up with that kind of title because it's what you end up doing.

"sudo" is unavoidable since the installs are designed to go into /usr/local. The other option would be to require you to run as root/privileged which leads to the same issue of running an unseen script and just adds an extra step to the process.

It's possible to design the process to allow installs into other locations but that would require a fair bit of extra configuration (picking up the libraries, etc.) and testing. And you'd lose the service startups. It's something to think about if there's enough demand (and probably required for supporting Macs)

There's a fair amount of risk in everything: Do you trust the admins of you hosting provider? Are you sure about the source code or binaries for all the pieces of your runtime stack? Did you audit every piece of your own source code for security issues?

But right now I'm not asking people to drop everything and use rayburst to set up their production servers no questions asked. Just to try it out and see if it does what they need.

If someone then decides to use it for production setup, we can talk about how to guarantee security and stability in the configuration for their setup. BTW this is why you enter into contracts, pay for services, etc.

I'm a fan of whatever gets the job done. In the end it's still scripting just with fancier mechanisms to get the process started and report back.

I spent a bit of time at the beginning of the project evaluating the two and ended up choosing chef because it was going to be easier to use this way (aka build something on top of).

I will say that it was easier and far less confusing to get puppet up and running initially. There's definitely a bit that needs to be worked out in the chef documentation. The "Ruby"-ness of chef wasn't really a deciding factor as I can work with just about anything as long as it's reasonable.

I definitely understand that there's a level of trust needed before you allow anyone get access to your system (or be it's provider). And it should be that way.

While I could describe what's going (and will right below), there's also the risk that what I'm saying doesn't match up with what's really going on. The best way to personally check what's going on is to set up a throwaway system and see if everything checks out. (You'll see that it does.)

So what is the process?

1. Install necessary os distribution packages to be able to build dependencies for the rayburst client 2. Download and build ruby from source 3. Install rayburst client (which includes chef) 4. Run the install for your server configuration 5. Report back success/failure of the install

You're able to see the install script that's downloaded via the wget command and as well as the recipes that are cached locally on your system (check the install output for the locations).

And the only way to be sure in the future that it remains this way is to have a trusted outside entity perform regular audits. It's a bit too early in the stage of this project for that. But it's one of the things I've thought about.

Part of the issue with Windows is that the out-of-the-box scripting capability just wasn't there. Compare writing a batch script with a shell or perl script.

Add to that inconsistencies in how commands handled spaces in names and issues with having to escape the '\'s in generated command lines. I know I would have avoided all of it if I wasn't being paid (well) to do it.

We're definitely looking into the right way to turn this into a commercial product...