alanstorm

It means if you have a PHP script or application (Wordpress, Drupal, etc) on your server, and there's code in the script or application that uses one of the `pcre_` functions, and that the regular expression passed to that `pcre` function uses user input to create a regular expression, then an attacker can theoretically run any unix command on the server. This means your user information (including any passwords in text files) is vulnerable, and it puts the attacker in a great position to gain full access to the server.

Until PCRE or PHP release a patch for this, you remain vulnerable. You'd want to defend against this at the web server level -- think `MOD_SECURITY` rules that scan requests, look for known "bad" regular expressions, and then stop that request from reaching the PHP application. If you have a good hosting company hopefully they're already doing this for you.

Has the experience remained the same?

Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.

However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)

For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.

Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to

1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries)

Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.

How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.

And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.

Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)

We're looking for a lawyer to help finish up our merger. The previous guy did 90% of the work and then stopped responding to our emails!!! This shouldn't take an experienced lawyer more than a few hours.

Pay: $10

One of the most damaging things in cultures where agreement is more valued than honesty is how it can sap the morale of your workers to the point where they turn into exactly the uncooperative super-negative people you were trying to avoid in the first place.

TL;DR; If you have the talent to do the sort of work these sorts of services require, then you have the ability to do it without them.

Just my two cents here (with the caveat I could be talking out of my behind since I don't know these people), but I'd discourage anyone considering a career in freelance design/development from using these sorts of services.

The hardest part of making a long term go at this sort of work is learning how to sell yourself and having the hard discussions about business, money, and commitments. Using these sorts of services rob you of that experience, and your working relationship ends up being more employee than independent, but without the hard fought protections employees deserve.

What these services promise you is high quality projects, and an escrow service for getting paid. You can, and should, set these sorts of protections yourself. If you are going to try out these sorts of services as training wheels, be sure to carefully read anything they have you sign, and make sure it could never be used to impact your future, 100% independent career.

That's solid advice, but only follow it once a sense of trust and rapport has developed between you and the client.

There's far too many things a potential client may not be telling you about the project, and it's incredibly hard for the independent freelancer to do enough business development, or for the client to do enough vetting, to know which random internet person is trustworthy. This is especially true when you're just starting out.

A one week sprint that solves a small, immediate need the client has will keep the project manageable, and protects both the freelancer and the client from a potentially bad situation. Worse case scenario, one of you is out a week's work. Best case scenario, after a few sprints a rapport and trust develops, and you can start providing your clients with estimates for larger pieces of work, knowing they'll be treated as estimates and not fixed bids.

Don't eliminate the appearance of uncertainty when you're legitimacy uncertain. That's bad communication. If a client needs solid estimates out of the gate they don't need an independent freelancer. They need a full-service agency.

HINT: For the purpose of this hint we'll assume your script is a bash script. If you've exploited the setuid program to run your script, bash may execute with the elevated permissions, but any program bash runs will run with your permissions.

I'm not sure how useful public shaming and griping are, but I do think it works on the iamayoungconsultantandnoonetalksaboutthis.com level. I'd have found the stories super useful as an insecure 25 year old "forced" into the freelance market.

Put another way, republishing an otherwise unavailable CC-licensed/open-source-licensed work is explicitly respecting the author's wishes, the author that published it under that license.

I doubt (but obviously don't know) Mark wanted to excise his work from human memory, he just didn't want the personal responsibility of maintaining those resources/participating in their development as a leader. That's the wish worth respecting.

Run the numbers, calculate the percentage of your income lost, and just consider it another unavoidable cost of doing business. I imagine you don't like paying Paypal, Google Checkout, or merchant account transaction fees, but I also imagine you don't feel personally slighted at having to pay them. Put people exploiting your refund policy in the same bucket.

If this is a subscription service, automate the refund process such that you can you can send a single email with a link that will let them provide feedback, cancel their service, and refund their money.

If you're selling software bits consider a serial number system that will allow you to remotely disable people who have requested refunds. Also, keep your refund policy but stop advertising it. This way you prevent bottom feeders from even knowing it's an option. If you notice this is costing you more sales than you gain, go back to advertising it and re-read paragraph one.

File under: Unintended Consequences. Also, Postel's law could probably be tricked into admitting itself as an accomplice.

1. Browser based Javascript provides a location object for managing and accessing the current browser location, and this location object is available as a global variable.

2. Browser based Javascript also provides a special case in the interpreter/processer/etc., where setting the location object equal to itself will reload the current page. This is also true for certain properties of the location object (href)

3a. There is also a more conventional reload method on the location object which accepts either a location object or string href. Also, many of the "go to this URL methods" exposed to Javascript will interpret "go to the url I'm at" as a request to reload the page. Many of these methods will accepts a location object, or a string representation of a URL as a paramater.

3b. location.href is a string representation of a URL

3. There are many ways to access global variables in Javascript. There are many ways to assign a value in javascript. There are many ways to call a method in javascript.

4. All of the above can be combined into lots (likely more than the 535) of ways to achieve the same thing.

Anyone know if this is related to the Fuel CMS (http://www.getfuelcms.com/) or are they separate projects?

I can't comment specifically on the Fuel framework, but it's probably going to take years (if ever) for "the right" way to use namespaces to emerge among the PHP communities. There's been a decade plus of ingrained name-spacing by convention that PHP developers will need to shed

You can't read Gruber in the same context you did five or six years ago. At this point he's an established journalisty blogger who depends on a network of sources, some of whom are within Apple Inc. That means, like most working journalists, he needs to consider the tone he takes with any individual article vs. what that article is going to do to his network of sources. The result is his writing still contains the smart incisive analysis it always has, but he also has to bend over backwards to make sure he's presenting what the the internal Apple take on the situation is. Compared to what you or I might say about Apple's behavior over a few beers, yeah, he comes off sounding like an apologist, but compare his coverage to what other in-the-tank tech writers say about Apple and he still comes off as an independent voice covering the company AND someone who can provide a level of context other people can't (details on Nitro's implementation)

Nothing ever wins, pendulums just swing.

It's probably a part of a longer term pricing strategy. It's hard to start charging "real" money (even $40/$50) for an application you were formerly giving away for free. People feel like you've taken something away. By charging a micro-payment disposable price of $5 (Happy Meal, Latte, etc.) they deflect a lot of that criticism and avoid some of the negative publicity. Over the next 10 years they can slowly raise the price, each time keeping is reasonable.

Apple's leveraging the work they put into building the App Store infrastructure (and business deals with credit card companies) to do something a lot of other companies couldn't (make something that was free cost something again without too much fallout).

Half of me says awesome, while the other half is slightly-creeped-out that scammers no longer need to stop at "nah, writing scraping scripts for bank websites would be way too much work!".

I'm not speaking for Stallman of GNU here, this is pure conjecture based on too many years of following these discussions. The "problem" with public domain software, (and BSD/MIT) style licenses, is people can take that code, make changes, and seal it back up into proprietary binaries where users lose access to the source code. The ideal world that the Richard Stallman character wants is one where if you're using something that was built with code, you have access to that code, and can't be stopped from using that code. Everything that people in the GNU camp do is towards that goal. Their choice to assert a GPL copyright (or copyleft, if you want to get really hippie) is a pragmatic one, because they recognize that the power dynamics of business lead companies to stop sharing most of what they're working on.

And lumberjack competitions.

All true, but somehow it's comforting to know that this client and this developer deserve each other.

No presumptions here, which is why an in-depth story would be so interesting.

There's an interesting story to be told about what makes someone who's already a billionaire keep on in such a hyper-stressful job/career/calling when facing repeated life-threatening illnesses.

We, of course, won't get that story, and will have to settle for a news cycle of the fiduciary responsibility tourettes brigade vs. the hacks who think they're John Gruber screaming at everyone to leave Steve alone.

A the risk of being tarred and feathered for pedantic behavior, the W3Schools doesn't post misinformation. They posted information that was accurate at the time, and then let is sit up there for 5-8 years as the state of the art improved.

[edited for grammar]

Hey, not a sidetrack at all, and I appreciate the link.

At the risk of putting this back on discussion though, from the outside EBS looks like a separate, but complimentary product for EC2, which will further muddy the waters for someone not familiar with Amazon's platform, which leaves room for a someone like PHPFog to swoop in as a middleman to provide a turnkey solution to the problem of getting PHP developers and Drupal/Wordpress site owners up and running in a scalable cloud environment. It's not that this is hard for someone to solves on their own, it's that for a lot of developers in the PHP Ecosystem there's too much inertia to get around to it.

When you "don't get it" do you mean for yourself, or for the market? If the former, you can stop reading, because for someone already up on EC2 and devops it doesn't make sense to insert a middle man. If it's the later, here's more to consider.

I think you misunderstanding may step from underestimating the time needed to make the right choice on an EC2 Cloud vs. Slicehost VM vs. Rackspace vs. Shared hosting vs. That guy with the space space in his rack for a PHP application.

For someone not up on EC2 they need to research what the difference between a Standard On-Demand Instance, Micro On-Demand Instance, High-Memory On-Demand Instance, High-CPU On-Demand Instance, Cluster Compute Instance, and Cluster GPU Instance is, and then decide which type of VM they need within that sub-group for their app.

Then they need to figure out where their application touches/stores items on the file system, and decide how they're going to restore that whenever they spawn/restart another EC2 instance. (file uploads, avatar image uploads, etc.) Lots of PHP applications make an assumption about about a readable/writable persistant file system (which, coincidentally, is why shared hosting is such a successful attack vector). The is where PHPFog having the Drupal and Wordpress installs come in handy, the implication there being they've solved that for you.

To get familiar with the EC2 infrastructure to make these choices, they need to make a $63/month investment or pony up the $227.50. Minor, but expensive enough that it creates inertia. If PHPFog gets their pricing right, or they have a compelling marketing pitch that this really is turn-key, they can capture a lot of mindshare right now, and possibly be a disruptive player in a segment of the shared hosting market that's been static for a long time.

None of the above is hard for a technically competent individual, it just takes time. It's plumbing, and (this is the important part), in the world of a PHP developer it's the sort of plumbing that up-till-now can be handled by a reliable shared host, or for larger companies/teams/apps, server operations folks who don't do application programming. That's why there's a lack of EC2 knowledge even among competent profesional PHP folks.

Add in all the people just using Drupal/Wordpress/Joomla/Magento/etc who aren't technically competent and you have a another market segment PHPFog could serve.

Are we looking at a $212 acquisition for PHPFog? Probably not. But that doesn't mean they can't be a successful company, or that they can't use a cash infusion to get the tedious-yet-requiring-a-brain work for getting default installations for all the popular PHP applications running.

If you haven't been paying much attention to EC2 until now, getting your head around the pricing structure, what plan makes sense, and the whole "You have a VM but no permanent disk" thing can take some time. PHPFog's value proposition would seem to be "We've figured out EC2 for you, and have default VMs setup for Drupal and Wordpress and a way to deal with those system's need for permanent disk space. If you can get your code in a git repository we'll handle the rest." Just getting Drupal and Wordpress out of a shared hosting environment is a huge win security/stability wise, and if their VMs have a configuration that deals with a lot of the well known attack vectors that aren't shared host related all the better.

I'm not sure that I'd use it myself, because I'd like to spend to time to get familiar with EC2, but with shared hosting becoming a less reliable solution as internet traffic patterns change (and shared hosts increasingly go he commodity route) there's going to be a lot of PHP professionals (and PHP hacks, and non-programmer hacks using PHP systems) looking for a turn-key cloud solution, so I can see the interest in PHPFog.

TL;DR: There's large swaths of the PHP community that doesn't know how to make EC2 work, PHPFog is aiming to be their middleman.

Could someone forward me the part of the article where it explains how an up and coming band can use a time machine to go back to an era where they can use the Recording Industry Promotion Machine to become a national act, such that they'll be able to build a large enough fan base to support a tour oriented business plan? Slate seems to be dropping that part in my browser.

I don't know if it will help you understand, but most of the time it comes down to trust. It's the rare client that will come out and say "I can't pay you because my cashflow is off this month, and I don't know if it's ever coming back".

Instead there's weeks, and then months of putting off, half-truths, lies, and the like. Most people new to freelancing trust that it's just some bureaucratic hold up, and the worst offenders develop entire personalities that are based on exploiting people's natural tendencies to trust other human beings. It usually takes getting burned a few times to learn that "the check is in the mail" translates to "I'm never going to pay you because the amount is small enough that involving a lawyer doesn't make financial sense".

You were over qualified for the position.

They didn't want a programmer, they wanted someone with known Drupal experience, who could hit the ground running, and wouldn't fall back on writing new software to solve a problem that could be quickly (if not perfectly) solved in Drupal. PHP based content management systems job are only tangentially related to programming. Drupal (and Joomla, etc.) exist so that companies can manage their websites without a programmer.

That may not be fair, but it's how the hiring companies (direct or recruit) will look at. If you want those jobs get a Drupal site or two under your belt, and downplay your 10+ years of PHP on your resume and during the interview conversation.

Video production of a live event can be pretty easily automated. It's not no work, but once you're setup to do it it's pretty simple.

Creating an accurate transcript of a live event is time consuming, and "hard" (well, it's tedious, which most people take to mean hard) to do right. Even if you don't any qualms crowd sourcing for something like this, you still need to manage the crowd sourcing, and get an edit cycle in there.

TL;DR; Free things are free for a reason.