[nSLUG] Looking for a DNS secondary partner
ian at slu.ms
Mon May 4 15:12:11 ADT 2009
On Mon, May 04, 2009 at 09:42:52AM -0300, D G Teed wrote:
> On Fri, May 1, 2009 at 4:46 PM, Ian Campbell <ian at slu.ms> wrote:
> > Reiser, for all intents and purposes, was ReiserFS. That's why v4 is
> > basically dead in the water right now. v3, on the other hand, is
> > stable (for some definition of stable) -- someone will have to squish
> > bugs found, and since it's open source anyone can. The vast majority
> > of people using it now can continue using it with no ill effects.
> Know of any distros willing to go that route for their default FS choice?
> It seems everyone has backed off the trend to go reiser that
> was becoming common a few years ago.
Which route? Reiser? No. It's no longer the flavour du jour. The only
group I can think of who ever made it a default was Gentoo, since
portage is a ton of nested directories and tiny files, an area where
There are plenty of reasons not to (ie woe be unto anyone who runs
reiserfs, keeps a dd image of a reiserfs filesystem on that disk, and
runs fsck...), but those decisions were made on a technical level, not
because Reiser is a bad person.
Anyone who is currently using reiserfs can continue to use it, it's
stable and there are still people who will commit bug fixes. For new
installs there are many better choices like XFS, JFS, etc.
What I never understood was why ext3 enjoys the popularity it does.
> I do keep all my mailing lists. Try using gmail. It is easier to search
> for information from mailing lists there than in archives on line.
Off topic: I keep some of the more interesting threads, but that one
wasn't really though. "Any ideas how I got hacked?" "Oh, it's an
ancient class of PHP vulnerabilities."
Skimming the thread again, I see nobody mentioned the allow_url_fopen
option for PHP. It will disable that (frankly idiotic) default
behaviour where PHP lets include/require/file_get_contents etc. open
remote urls if you set it to false in php.ini.
> > Of course support is important, but so is not getting hacked, and so
> > is not having your app run dog-slow. If security and performance
> > aren't factors in your decision making process for what runs in
> > production, you may want to rethink that.
> In terms of picking technology, which is what this discussion was
> about, I can't unpick php. So that is out of my hands.
You can write secure code in any language, you can write insecure code
in any language. PHP doesn't make it significantly easier to shoot
yourself in the foot than perl/ruby/python/C/whatever if the coders
aren't going to validate input to begin with.
> It wasn't my php code that was used by the hacker.
> We are in the same situation as hosting ISPs, where newbie
> php code or unmaintained web applications can be abused.
> We are constantly improving the security of this.
My mistake, I'd stopped reading the thread around alienform.cgi.
More information about the nSLUG