sgerrand

The latest repository being used and advised for this attack is https://github.com/notification-on/gitcoin.com.

Even more confusingly, "ate" is pronounced differently depending on the temporal tense: https://www.thefreedictionary.com/ate

I don't compile my own software against glibc and run it in Alpine. As mentioned previously, this package was created ~ 6 years ago to run software compiled against glibc (that didn't have the source code available) in Alpine Linux. I don't recommend that anyone uses it over the equivalent Alpine package or compiling your software against musl-c.

Ah, thanks for the pointer. The blog post referenced the Alpine package I maintain but was obviously implicitly referencing those Docker images.

I don't provide "alpine-glibc" Docker images or containers, so I don't really know what you're referencing here. I maintain an Alpine package called `glibc`. Please enlighten me!

Maintainer of the Alpine package referenced here. It's called `glibc`, makes no claims on Alpine Linux and certainly isn't a Linux distribution. You install the package in Alpine Linux, nothing else.

Maintainer of the Alpine package referenced here. The same name for what? The package name is `glibc`. I think you're confusing/conflating the source control repository's name with the package when they are different things.

Maintainer of the Alpine package you referenced here. I'm not a "them". ;)

I don't see where "Alpine" is used in the package name, unless you're referring to the source repository name. In case it isn't clear, `alpine-pkg-` is a prefix which denotes that the repository contains an Alpine Linux package manifest and configuration. There's nothing in the repo itself which states that this package is published and/or endorsed by Alpine Linux.

Maintainer of the Alpine glibc package referenced here. For some background context, this package was originally created to solve a specific problem long before Alpine provided glibc compatibility packages like `libc6-compat` and others. I agree that this package shouldn't be considered "blessed" or an official Alpine package or a default solution for running programs originally compiled against the GNU C library on Alpine Linux, far from it. The source control repository uses `alpine-pkg-` as a prefix to denote what it's used for—not as a means of assumed official status or such like.

What I find saddening is to see passive aggressive statements like

I have additionally suggested that the TSC may wish to have the Alpine Council reach out to the alpine-glibc project to find a solution which appropriately communicates that the project is not supported in any way by Alpine.

To the Alpine Linux TSC: please get in contact with me about any and all disclaimers you want to add to this package! I'd love to have these discussions faster and in the open, rather than discovering this disquiet tangentially. Let's get these issues resolved as soon as possible in a way that everyone concerned finds acceptable.

I'm assuming the author was referring to this plugin: https://github.com/smashedtoatoms/asdf-postgres

Have you looked at the API documentation or user guides? It seems like you've commented on marketing aspects without looking at the product itself.

Have you looked at the Haskell QML bindings? They generally work for cross platform requirements.

http://hackage.haskell.org/package/hsqml-0.1.1/docs/Graphics...

What you are seeing/referencing is the output of commands during earlier runlevels; the X server won't start until runlevel 5 (number selected off the top of my head). That said, it'd be good to give users of mainstream Linux distributions like Ubuntu the option to suppress output from the boot scripts.

Year of Linux on the desktop, here we come!

There's a typo on the README site that might indicate that they had similar ideas: `Google Analtyics`

Sadly, this blog post appears to me as an over extrapolated version of "write tests for your code: you'll thank yourself later". I don't see what it adds to the topic, apart from a confessional component.

I find it saddest to see a university graduate with an honours degree (cum laude for the Yanks) and majors in economics, philosophy and politics go straight into marketing. In particular, 'social' marketing. Maybe that's just the way it is these days.

Yet another article from a marketer taking up programming. I wish the OP the best of luck in this endeavour.

Actually Facebook agrees with me so much that they rewrote PHP as a C++ macro called hiphop, and no longer use PHP.

A specious comment - hiphop transforms PHP to optimised C++ and then compiles it.

https://github.com/facebook/hiphop-php

As previously discussed on HN, Robert Eisele's fork of PHP (at v5.3.6) which attempts to fix many of the issues.

http://www.xarg.org/2011/06/php-hacking/

A large number of people have previously pointed this out. You're selling the virtues of mod_php, rather than PHP itself.

As other have pointed out in this thread, you can easily configure a web server to behave like that for files in other languages like Perl or Python.

Great work!

I've created a WordPress plugin for this - it contains the JavaScript file locally to reduce the potential load on the js.sopablackout.org domain. YMMV.

https://github.com/sgerrand/sopa-blackout-for-wordpress/

I experienced the same issue.

Perhaps visiting the W3C website (http://w3.org/) is a good place to start if you are looking to understand how the Web works. Learning to "code" is not a short journey for the uninitiated, but the journey can be a valuable and rewarding one.

the 'security' block should really be at the top of the README. lines like "fredit has rudimentary security features." just underline how much ruby needs perl's taint option.

while I could use the private 'secure_path' method in the fredits controller as a initial point where the gem could be improved, I think that it's better to just say 'do not use this' instead.

tjriley82's comment paraphrasing the "teach a man to fish" aphorism makes more sense to me.

Using a search engine would give you numerous examples (c.f. https://duckduckgo.com/?q=php+security+hole )

Actually asking for examples sounds like a trolling attempt to me.

As should we all.

Kudos on a well implemented use of AppEngine - It's really zippy.

Do you have any plans to write a technical overview of your implementation?

Obligatory 'real programmers' links:

* http://www.pbm.com/~lindahl/mel.html

* http://xkcd.com/378/

This article suffers from a lack of editing - it could do with a rewrite to improve the readability alone Apart from this, some of the points are somewhat glib, if not outright specious:

* PHP can do more than 'web' - the functions that fall outside of 'web' (process control and semaphore come immediately to mind) have wildly inconsistent quality and are generally not supported outside of POSIX based operating systems. This reflects on PHP as a language on the whole - part of the language and its extensions are well written and documented, many other parts are not. Prolonged use of the language just repeatedly reminds the developer of this, which becomes tiresome.

* PHP projects are not reusable - While the example given (Wordpress) is widely used, the project is somewhat cumbersome to extend because of the mix of application and presentation logic. Also, using Wordpress is not the best example to use, given the amount of security issues it has faced[1].

* PHP is not good for high performance scalable Web sites or applications - There is a claim regarding the HipHop for PHP (H4P) project being solely about making PHP into a citizen of the multi-threaded web server module world. The performance improvements in execution speed provided by H4P show that the benefits of compiling PHP scripts via interpretation into C++ are far more than just providing multi-threaded instances. This part of the article also continually refers to CPU being the key benchmark for intensively used websites. In the real world, applications generally consume more memory than CPU. PHP handles memory use poorly. That alone appears to have been the motivator behind the H4P project at Facebook. Using PHP in the real world means that a series of caching technologies (opcode - e.g. APC, frontside - e.g. Varnish, memory - e.g. memcache) are required to support large amounts of simultaneous users.

In summary, the article detailed and answered many fallacies regarding PHP that are littered across the web. The inclusion of statements that are 'loosely' true and glossing over innate inadequacies in the language reduced the article as a whole. As a result, it underlined the reasons why I do not choose to write any programming code in PHP at all any more.

While I can see the reason for responding to a series of specious assertions regarding PHP[2], a better response could have been made.

[1] https://encrypted.google.com/search?q=wordpress+security+iss...

[2] http://java.dzone.com/news/i-php#comment-54511

So why not use Perl then?

Agreed. More details on if and how automatic scaling was implemented would be good too.