lnguyen

Those people aren't after an answer. They want the captive audience.

None taken... I've added some info about me on https://rayburst.com/company

Here's what it says:

"Long Nguyen has nearly 10 years experience as an enterprise build and software configuration management consultant and remembers having to install his first Linux server from floppy images that were downloaded using a 14.4K modem in his Harvard dorm.

Long has a PhD in Physics from The University of Chicago and got a crash course in the world of startups as part of the YC W08 session."

FYI the recipes are all custom written. The community ones are aren't very standardized and usually are only good for installing from distribution packages.

(And if you look through the install output, you'll also see where they get stored on your server if you want to review anything that's being done.)

It's true. And I'm not running a stealth botnet or anything.

I'm just better at building things than trying to write marketing collateral.

Feel free to email me directly at long at rayburst.com

As soon as I can get a VM loaded and run through the install catalog. I should be able to get that taken care of by the beginning of next week.

It's mostly to fix any build dependencies that have to be installed as distribution packages have name updates. There were a handful between 10.04 and 11.10.

Thanks. I'm more backend and ops than design and UI. So things like figuring out obscure compile flags comes easier than CSS.

The client gets installed in /usr/local/rayburst and data for your install goes under /var/lib/rayburst. It's done so that it doesn't get in the way of any of your actual installs (had enough conflicts with system ruby when testing). And you can clear out those directories once everything is installed.

All in all the current design is to get things installed on a new server and then get out of your way.

If you haven't seriously used branches before, git can be a bit hard to wrap your head around. And trying to map it back to what you're familiar with in svn adds to the frustration.

The best thing to do is create some "play" git repositories and see what happens when you run any command. You can also run "git clone" on local directories to mimic actual remote repositories without having to set anything up. Don't worry about screwing anything up as you can just delete the directory and start over.

How exactly do you define "traditional unices"?

Based on what you've posted,you'd have a hard time calling anything that. And I'm including AIX, SunOS/Solaris, HP-UX, etc.

What you want is a UNIX or UNIX-like OS that comes pre-installed with GNU-based development tools. This is a choice in configuration, not a definition of what UNIX is or isn't.

I never use fink, macports or homebrew to install on my Mac. It's pretty much download source, take a look at the README/INSTALL and go from there.

The main issue is that Mac is probably not the usual target system for these builds (in comparison to a mainstream Linux distro). And as such differences in the version of the compiler, the set of libraries, installed dev tools, etc. may lead to build issues. You might have to download a few more things or know to add or override compiler or link flags.

Even with the latest Ubuntu or Fedora distro, you still run into having to know that you might need to install dev files to get a build from source to work (recent example for me is pcre libs for nginx).

Macs aren't configured from the start as a development system. And if you start from a UNIX or Linux distro that isn't either, you'll encounter into the same issues (or worse) with trying to run "./configure && make && make install"

It's the same as any recommendation engine: Because you've bought x, based on similar patterns from other customers you're probably likely to buy y. The fact that it's pregnancy-related makes for a good (and slightly controversial) news article.

Throwing in the additional information that exists outside their system can lead to even better and timely recommendations.

They've already been in services ala IBM for a number of years.

If you have the money, you might as well buy a company that already has product and data. Time is money. As far as only date-based info, this is data that they can't automatically get from within their system (aka matching purchases with specific credit cards).

You're already working in the multiple repository approach (project and local). It's (almost) impossible not to with git.

It doesn't affect how you use git for moving files/versions around. What it does affect is how you communicate with one another. You both are seeing the same thing and aren't wasting time trying to explain how to get the same info in the different tool.

Treat it like a citation in a paper. Add comments acknowledging and saying where the code came from. If nothing else, it'll help refresh your memory on why you needed it.

Also be aware of the original licensing for the code. If it's any more than attribution you'll need to determine how it affects the rest of your code and if you might need to reimplement.

You do realize that the tools have to be created based on some underlying process. If you have an understanding of that process you'll have a better understanding (and appreciation) of that tool. And maybe be able to come up with a better one.

The issue is whether you learned the actual skill (graphing, factorization, etc.) or just learned how to get the calculator to do it for you.

In many cases, the end results appear identical. However, I'd rather the upcoming engineers, scientists and mathematicians be banned from using calculators for anything more than basic arithmetic until they prove they do understand the concepts.

It's not only that it might be cheaper, it's because it takes out the uncertainty that would be involved in trying to defeat a patent. You have no idea how long the fight will take to wind it's way through the courts or even if you'll ultimately get a ruling in your favor.

It probably would help if they had an outside auditor to verify the actions that were taken. Still wouldn't be final proof to anyone who believes that they might still be hiding something but is a step further than just saying "trust us".

Right now it sounds like he's just trying to see what the possible solutions for his issues are. If he can provide additional benchmarks, etc., great. But he's under no obligation to provide any more than he has. Once there's a solution, then maybe.

I don't think Facebook is claiming to be.

And as much as I'd like being truly open as an ideal, it falls apart when you're dealing with competition (not cooperation) and money. At best you try to keep things open enough.

I'm pretty sure that cloning a repository of that size can't be all that fun.

You tend to split repositories based on team responsibilities. I doubt that every developer needs access to update all million+ files.

What this comes down to is that they've made certain architecture decisions that ideally would be changed but it's not possible to do so at this time.

It's intentionally vague but with enough details that if you're actually in a position to help, you'll recognize what's going on and actually directly contact to get more information.

You don't spill internal processes and configurations without some kind of disclosure agreements and certainly not in a public forum.

There's two issues: the width of the repository (number of files) and the depth (the number of commits).

Since "status" and "commit" perform fairly well after the OS file cache has been warmed up, that probably can be resolved by having background processes that keep it warm. (Also, how long would it take to just simply stat that number of files? )

The issue of "blame" still taking over 10 minutes: We need to know far back in the repository they're searching. What happen if there's one line that hasn't been changed since the initial commit? Are you being forced to go back to through the whole commit history?

How old is the repository? Years? Months? I'm probably guessing in the at least years range based on the number of commits (unless the developers are extremely commit-happy).

At a certain point, you're going to be better off taking the tip revisions off a branch and starting a fresh repository. It doesn't matter what SCM/VCS tool you're using (I've been the architect and admin on the implementation of a number of commercial tools). Keep the old repository live for a while and then archive it.

You'll find that while everyone wants to say that they absolutely need the full revision history of every project, you rarely go back very far (aka the last major release or two). And if you do need that history, you can pull it from the archives.

I'm pretty sure the mod community would disagree. id, epic, etc. wouldn't have released editing tools if they didn't expect modifications to be made. But the expectation is that you're going to make that available back to the community.

If you're trying to just simply take someone else's IP and make money off their work without their consent, that's something else. Negotiate a license and get out of the grey zone.

They've trained the public for generations to not use their imagination and creativity. The withdrawal is probably painful enough to keep them going for a while even past that point.

It's not just innovation but how they're executing and winning market/mindshare.

There's already been a rich culture of mods, re-contextualization and remixing. You've been able to do all of the above before this release of the source code.