mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

One of our volunteers, [personal profile] kaberett, published an article today.

It's a really great post that captures one of the things that I really think is crucial to Dreamwidth's success as a project (and business), and it's the idea that anybody can contribute, everybody is valuable, and yes -- mistakes can and do happen and it's OK.

To pull out a bit from the article that really resonates with me:

[I]nstead, we work towards fostering tech confidence, through creating a culture where babydevs know that senior devs have their backs; a culture where people feel able to ask questions of the broader community, in public as well as in private; a culture where people learn how to test and debug and Not Give Up; a culture where our co-founders own their mistakes, and do so publicly, so that nobody has to feel alone. When people get discouraged, we give them pep talks. We remind people that it's okay to learn visibly, instead of having to pretend to be entirely competent all of the time. Everyone can learn from the mistake that anyone makes – and mistakes are caught soon after they happen, so consequences can be minimised.

Yup. Couldn't have said it better myself.

Contributing to Dreamwidth isn't about how much you bring to the table when you get here. We don't care how much experience you have or what your resume says or if you even have one. The fact that you're here and that you want to contribute? That's all you need. The rest can be learned.

mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

We had a server lock up today (this is fairly normal and our infrastructure is resilient against it, so no downtime happened!). Anyway, there was an email thread that is pretty typical of how things happen behind the scenes here, so I figured I'd reproduce it here. (With permission!)

[personal profile] alierak: Memory usage suddenly went through the roof on lb01, which is really just a web/mogile server and doesn't have perlbal or varnish set up. I can't get into it to fix anything, I think we'd have to have ServerBeach powercycle it, but I'm not going to be around this evening.


[staff profile] mark: I'll take this one -- enjoy your evening! :)

I agree re: the powercycle, although I am going to give it 10 minutes and see if I can possibly SSH in. If it's swapping, it might eventually let me in and I can see what happened...


[staff profile] mark: It's back. I never got in via SSH and rebooted it. Took ~25 minutes to come back up -- fsck it looks like -- but it's back and serving requests now.


[staff profile] denise: maybe it just wanted a nap.


[staff profile] mark: We don't allow our servers to nap. It's not in their contracts. They have to be up 24/7/365.

They're not even allowed religious observances.

It's really kind of a bum deal.


[staff profile] denise: let's hope they don't decide to unionize! i'm trying to remember if there's ever been a rabbinical ruling about tech companies owned by jews who keep shabbat strictly, and whether the servers can stay up during. on the one hand, you're not supposed to cause any fires to be kindled (which modern observance takes to mean no turning-on of things; electricity = fire), which means that using a computer is forbidden. on the other hand, servers are on all the time, and the restriction is generally held to be only on turning-on: things that are on all the time are all right. (if you remember abusefest '05: desh turned on the living room and bathroom lights ahead of time and taped an index card over the switches saying "please do not turn these off": that was okay, because the light was turned on before the shabbat started.) so a server that's always-on wouldn't be "melakahah", or "causing work to be done". so it would probably be acceptable even for people who kept strict observance. but i'm really curious if there's ever been a ruling, now!

--D, who is not going to get sucked into researching that...


[staff profile] mark: hahahahahaha -- can I post that to [staff profile] mark? "a look into the life of DW at work". :)


[staff profile] denise: lol. feel free, someone might know the answer <3


So there you have it: a day in the life of Dreamwidth behind the scenes!

mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

Someone on IRC was talking about the origin of the name Dreamwidth Studios. I think this has never been posted before, so I went and dug up some old emails. These are all from March and very early April of 2008. I pulled out relevant sections, too, so they're slightly diced up.

Anyway, I hope people enjoy this. This all took place on the "Project Crazy" mailing list, which is what I called it. Because really, we all had jobs and lives, this was kind of an insane proposition. Yet here we are today.

In the beginning, Denise wrote:

I'm going to pull together points that were made in the irc discussion tonight and start separate mailing list threads for them so we can have fistfights about them separately and don't get mixed up. :)

So, here's what we've decided on names:

1). Doesn't contain "journal"/"press"/"movable"/etc -- anything that reflects on existing branding
2). Short and easy to type
3). Easy to abbreviate to a few letters
4). Contains an immediate sense-impression/identity/"brand" of what we're trying to do: grassroots, collaborative, user-driven, open, creative, not motivated by profit, frontier-web
5). Is unregistered so we don't have to buy it from squatters
6). Not connected to writing/journaling -- we're for all forms of creative expression

To which I'd add:

7). Not easily subjected to the playground treatment of subbing in a rude word
8). Available cross-TLD (at least we want the .org and either the .net or the .com if we go that route; I'm also open to alternate TLDs)

I've got registered, which, yeah, not perfect by a long shot, but at least we have something. I'm so not married to it, though.

Here are some of the alternate ideas I was dreaming up with a friend: (.net, .org also available)

Mark's not sold on the verb thing, though, since it's hard to verbally shorthand ("Yeah, I have a _ [LJ, GJ, Vox, etc]").

So ... open brainstorm, go go go!

Mark replied:

Yeah, pretty not sold on the verb thing, but if you think it works then I trust your judgement. Anyway, I was trying to think of something in Latin earlier, something about fantasy or dreamers or those who create, but I don't really know Latin and the web was failing me. That or some other language might work, a word that sounds like something neat, but really means something. But then, that's my own particular fancy, I like Latin words.

I don't have any new ideas, just tossing that out. Of the below though, I think I like dreamwith the best. Dreamwidth? DW? Meh.

Denise further replied:

Hmm. are all free, and is also
available (for common typo-squatting). If we used --
"dream-width! it's like bandwidth!"

Okay, okay, kind of lame, but DW is a good shorthand for that.

OTOH, potential for confusion with Dreamhost.

Maybe we should make a list of words that we feel apply to the
service. (I believe that in Web 2.0 Circles this is known as
'whiteboarding'.) I'll start:


...for a writer, I should be able to think of more words.

Jesse (jproulx) chimed in:

Some latin words that pertain:

libre -- free (speech)
gratis -- free (beer)
cogito -- think/ponder
creo -- create
perscribo -- write
somnia -- to dream
somnium -- dream/daydream
dico/dictum/dicto -- speak
lector -- reader
recito -- recite
fabula -- story/fable


creolibre ... create freedom. Meh.

We should keep this ball rolling though. I dunno if we want to somehow involve some other people in naming a hypothetical site. Of course, we also don't have to name it right away, and can put the company under some name that is mutually agreeable and then stage the site somewhere and give it a proper name.

Denise, who has far better Latin than me, corrected me:

It would be creatiolibertas -- "creation of freedom" ... although
"libertas" would decline, too, so i'd have to get out my dictionary
to figure out what declension it was.

(I took three years of Latin! It has always annoyed me that the OSS
movement uses 'libre', since that's not correct latin. g)

(I still think I like, though. It's my current favorite.)

John (idonotlikepeas):

Hmm. I actually agree with Mark on the verb/noun thing. A noun-based name is easier to brand. Dreamwidth is an interesting suggestion, though. Have to think about that one.

Denise rolled it back:

How about cycling it back around to the dream/dreamwidth/etc thing
that we were going with? (I still really like it, it's easy to brand,
and it's available .com/.net/.org + one major typosquat.)

(Also remember: domain name + company name + service name don't
necessarily all need to be the same thing.)

We could go with:

-- Service name: DreamWidth Studio, abbreviated DWS, domain name ("I have a DreamWidth" or "I'm on DWS")
-- Company owning DWS: DreamWidth Studio Coalition

Deciding he liked it, Mark acted:

I've just registered:

dreamwidth .org .net .com
dwscoalition .org (.com .net available)

Whether or not these are final is irrelevant. Just wanted to get them just in case.

Denise proposed we accept it:

Mark needs a final go/no-go on the name/domain name, in order to get
the SSL certificate. This is hereby the formal roundup thread:


-- The social media/blogging site formerly known as Project Crazy
shall now be known as DreamWidth Studios,;
-- The following domains will redirect there: http://, (and further to be
-- The business will be initially registered under the name DreamWidth
Studios Coalition and use the domain;


[ ] Yes, I agree
[ ] No, I've got a better idea (and describe:)

The name was accepted. Later, the issue of the camel-case came up, and Denise said:

I vote for "Dreamwidth", no StupidCaps.

And so it was written, Dreamwidth Studios was born.

mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
I don't have a lot of energy left in my right thumb to type at the moment, but ... I'm back. It was a fantastic trip. I was really sad to leave.

There is, in my heart, a warm and fuzzy place that wishes and hopes for Dreamwidth to get to the point where we can do this sort of thing regularly. Also to be able to really hire people, have an office, and work on awesome stuff together in that sort of concentrated, high bandwidth way. Making something awesome for people to use is just so satisfying and wonderful.

One day, Internet, one day...

As it is, though, it was great. It was good to meet new people I haven't met in person, see some old faces, and sit and hack. Plus attend the conference, heh, although honestly that was a smaller part of the whole thing for me. It was mostly about getting Dreamwidth people together and hacking.

I'm full of warm proud fuzzies.


Jul. 15th, 2012 11:13 am
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
I arrived in Portland yesterday, a day before most. I am doing a bit of adventuring with my partner Ari and our small child Oliver -- he is almost 8 months old!

Today the rest of the Dreamwidth contingent is arriving. We are putting everybody up in the same hotel for great opportunities to hack and hang out. It promises to be a super exciting week full of great talks, making better connections, and hacking!

Stay tuned. :)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
This is a short-ish post about some of the more interesting and relevant things I've been learning about and seeing in action. I won't spend a lot of time in this post, but I want to make sure I get them written down.

1. CHI. This is, basically, the DBI for caching. It lets you do some really interesting abstractions on your caching system. For example, you can write code that looks like this (from memory):

my $val = $cache->compute( "uid:3943", "10m", sub {
    return LJ::load_userid( 3943 );

This code replaces the following paradigm. We use this everywhere:

my $val = LJ::MemCache::get( "uid:3943" );
unless ( $val ) {
    $val = LJ::load_userid( 3943 );
    LJ::MemCache::set( "uid:3943", $val, 600 );

That is a simple example. CHI also lets you do things like chained caches (think L1/L2 processor caches) and cache mirroring (write to our database and memory) and etc. It's interesting.

2. Exception::Class and Err. These are just some of the classes, but it's the whole "use real exceptions, throw them" instead of "die or return undef and handle it everywhere". Yeah. I like exceptions, I think we could do well to start using them.

3. Message::Passing and family. This may not be directly applicable but it's interesting. The whole ZeroMQ world + the idea of removing Apache. We would have Perlbal package up requests and send them back to the web server jobs -- whatever they happen to be.

I really want to ditch Apache. We aren't really using it for any good purpose. We don't really need a web server. We can jettison it.

4. Bread::Board. Let's be honest, our application is really complicated. This system lets you simplify some parts of that -- so you don't have to manage dependencies and some things like that. It also really helps with abstracting things to a central configuration point.

We really should work on making Dreamwidth more modular. Separating "areas of concern" so that we have separate, smaller components. This makes debugging, performance analysis, and lots of other things way easier. It also helps with the whole modernization front -- and being able to enable or disable systems that are a problem.


There are lots of interesting talks. Lots of things that are coming back into my mind -- using Moose (or a similar real object system), relevant testing, documentation, better exposure (getting Dreamwidth more recognized in the industry), etc etc.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
A few of us Dreamwidth people are at YAPC::NA in Madison, WI. Denise, myself, and one of our volunteers -- although I can't type the username from memory, alas! (Momijisomething!)

The keynote this morning, by Michael Schwern ([ profile] schwern), was utterly fantastic. If you haven't read my previous post titled The Meritocracy is Harmful, you might want to take a moment and do so.

While Michael didn't come out and make that same claim, what he did say is that the meritocracy as we like to think of it does not exist. We like to think that open source is founded on and run on merit. It's not. It is an aristocracy -- a dictatorship. (All of our pretty little fiefdoms...)

The problem with this kind of system is how much it promotes and enforces homogoneity. This is why only 2-6% of open source contributors identify as women. Yes, this is a problem. Yes, we should do something to fix this.

I am proud of Dreamwidth and what we have accomplished and who we are. It is super exciting to me to see that the keynote at one of the major industry conferences -- notably, though, non-commercial! -- is on the very issue we've been talking about for years.

So happy.

Now I hope that the rest of the conference lives up to the opening. :-)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

Yes, yes, yes. This is the kind of message we need more of in the world of open source, technology, and the Internet. The quote brings tears to my eyes.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
First, let's start with the genesis of this post:

The whole thread is worth a read (in the sad train wreck sort of way), but I want to call out one particular quote by Linus Torvalds. If you aren't familiar with him, he's the guy who started Linux. He's widely respected and revered in the circles of Open Source and technology and what-have-you.

> Btw, Joseph, you're a quality example of why I detest the github
> interface. For some reason, github has attracted people who have zero
> taste, don't care about commit logs, and can't be bothered.
> The fact that I have higher standards then makes people like you make
> snarky comments, thinking that you are cool.
> You're a moron.
>                    Linus

This is unacceptable behavior on a peer to peer level, let alone from someone who wields as much power as Linus does. Publicly humiliating someone is ridiculous and speaks to a broader problem in the world of open source and technology in general.

If President Obama were to speak like this to someone, it would be extremely damaging to him politically without some very immediate and strong damage control. Power puts a certain onus on you to behave "above reproach" in ways that normal people are not held to. (Although, IMO, normal people should hold themselves to such a standard -- it's just that the public generally won't.)

Returning to this particular issue: what do you think will happen next with Joseph here? I expect there are two likely outcomes: either he will abandon his interest in open source/kernel development/technology and go somewhere else where he will be appreciated and be able to grow and learn, or he will continue on and learn to fight fire with fire and perpetuate this nonsense on to other people. After all, everybody wants to be Linus Torvalds -- the guy is famous and incredible! -- so clearly this is what we should all act like, right?

The excuse that many people offer here is that this is all a meritocracy. I.e., if Joseph had been worthy (note that this is defined here as "uses a 72-column line wrap boundary"), he wouldn't have been the subject of such an outburst! Everybody can learn from this and Joseph can go be a better man and eventually he will have a place in our society built on our noble ideals of ranking-by-IQ! It'll be awesome!

But in reality, what have we built here except a different way to wage war and hurt each other? Instead of guns and bombs, we use our voice: the pen is mightier than the sword.

Do we really want to be the proponents of a society that accepts and encourages such treatment of our fellow men and women? (Oh, sorry -- just men. We don't really have women here because we have built a system on Othering and exclusion and harassment and we consider it acceptable and then stand around wondering where all the women went. But that's a topic for a different day.)

When put in those terms, though, you probably disagree with me. "No way! That's now how it is at all!"

But look around. Linus Torvalds, arguably one of the most powerful men in open source, just descended from his ivory tower and graced us with his presence and wrote what he did. And nothing will come of this because nobody cares. Well, nobody who matters cares. If you have any doubt, let's go back to something from February, where Linus said this:

Whoever moron thought that it's "good security" to require the root password for everyday things like this is mentally diseased.

So here's a plea: if you have anything to do with security in a distro, and think that my kids (replace "my kids" with "sales people on the road" if you think your main customers are businesses) need to have the root password to access some wireless network, or to be able to print out a paper, or to change the date-and-time settings, please just kill yourself now. The world will be a better place.


If you look at the bottom of that link, you might note that Linus has gotten over 6,400 upvotes for suggesting that some people should go kill themselves. I went and read through many of the comments and could only find four that called him out for his text. Out of hundreds of comments from people agreeing with him or otherwise finding what he said to have some sort of merit and worth.

There is something extremely wrong with the world of open source and technology when this kind of behavior from one of our leaders is considered acceptable. It's heartbreaking, honestly.

What I'd like to end this post with is some sort of solution, some way to fix the problem. But I don't know what it is and I don't know where to find it. Instead, I will just do my damnedest to make sure that my little corner of the world, Dreamwidth and the other projects I touch, hold ourselves to a higher standard of behavior and expectations from our contributors and staff.

Thanks for reading.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
I was curious about where most of our traffic goes, so I did some stats. This is for the last three or four days (it varies depending on the log files) across our cluster. Note that this only includes things that have hit the webservers. It does not count things that Varnish cached or were static files.

Top 50 by pageviews )

As expected, the main site (which hosts userpics too) is on top by a lot. Also, I expected the meme journals to be high, but I kind of expected them to top [community profile] scans_daily. Apparently not! Well, good on you all for being our most popular destination. :)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Things are calm at the moment, so it seems a good time for me to ruminate on the current state of Dreamwidth's load/capacity/etc. Please let me know if anything is unclear, or if you have any concerns, or whatever -- I'll do my best to answer everything.

The summary -- Dreamwidth has definitely been hit with a lot of extra load in the past few weeks, but it's maybe not as much as you thought. We're over double what we were a month ago, but it's still only double -- we already had a good amount of load. Here's a good graph showing the bump:

Dreamwidth Bandwidth Usage

There are several main "systems" that make up Dreamwidth (or, really, most web sites). They are the frontend, the web servers, the cache, the databases, and the miscellaneous services.

Let's take it one by one... we'll start with the easy things. We're going to talk about the current state of stuff and the scaling of it. This is a term that loosely means "making it handle more traffic". (Where traffic is more users, more features, more whatever.)

Miscellaneous Services

These are pretty straightforward. Scaling these is, typically, a matter of just running more of them. We're nowhere near capacity on most of these, and any that are, we can just run more of the worker processes. I'm not too worried about these -- even if they do get overloaded, they won't stop the site itself from working. People can still read, post, and do stuff.

If these overload, it will affect emails going out, search, payments, and similar things that are considered non-critical services. (I.e., if search goes down for a day, it's frustrating and I will do my best to get it back online ASAP, but it's a lower priority than web servers or databases.)


We use memcached for most of our caching. Having this service online is crucial for the site to be working -- without our cache, the databases will overload and croak. No good.

Thankfully, though, this system is nearly free to scale. All we have to do is deploy another few instances and update the site config to use them. The downside is that adding more instances will cause the site to slow down for a little while because the entire cache has to be emptied and redistributed across the new, larger cache cluster.

We're getting close to the point where I want to deploy new cache instances, and I will be doing that when I get the new databases up and ready. I'll schedule it for a low traffic time so it should have minimal impact on the site.

I'm very comfortable with our status here and our ability to scale out for more capacity.

Web servers

These are the actual machines that handle processing the web pages, as you might expect. The nice thing about them, though, is that they are horizontally scalable. This means that adding more of them adds more capacity in a linear fashion. If we have ten web servers and they're overloaded, adding ten more doubles our capacity for this service.

We currently have six machines handling web requests and we can easily add more. It just takes about 48 hour notice to our hosting provider to get them to spin up and deploy a new machine. As soon as I notice us getting close to capacity on this tier, I submit a request and we get more up. Since the big bump of users two weeks ago, we've added two more web servers. If the load holds where it is now, we'll stay at this level -- but again, it's easy to add more.

I'm very comfortable with our status here, too.


We're currently running on MySQL databases. These machines are a lot more expensive than web servers -- more RAM, fancy disks, a RAID card with BBU, etc -- and they're a lot harder to scale than the webs. Harder, but not really impossible.

Physically, we have two machines. Logically, though, there are two types of databases -- the global database cluster and the user clusters. We have to talk about scaling the database in terms of its logical components, since they have different scaling requirements.

For the user clusters, these are effectively horizontally scalable, just like the web servers. We put online two more machines and we create a new user cluster, then we start moving people over to it. We can balance the load on the user databases by increasing or decreasing the number of users that "live" on that machine. You can see what user cluster you're on with our Where am I? tool.

The global cluster is harder to scale. There are some bits of data that have to live in one place because running it in several places makes code very, very hard to get right. Think about it like having two bosses -- if you have two bosses who do the same thing, you're never really sure who to listen to. Jim may tell you to work on project X, but Sally might say work on project Y. How do you decide what to do?

On the plus side, our global cluster is a lot, lot smaller than the user clusters. It only stores things like payments, user login information, and some other data that is pretty small and lightly used. It has a much higher capacity (how much load we can throw at it) before we have to consider scaling it.

Even then, scaling it can be done by adding more machines in as slaves -- i.e., exact copies of the master global database. This will buy us a decent amount of headroom before we have to consider doing something fancier like moving to SSDs instead of rotating disks. We can also add more cache machines to give us even more capacity.

We're hitting close to capacity on our existing databases, but we have two more machines on their way right now. They should be set up pretty soon (in the next day or so) and then we'll have more than double our current capacity. Also, we're still running on a MySQL version that is two years old -- there have been a lot of improvements to MySQL (particularly the Percona branch) since then, and I will be upgrading us soon.

All told, I'm pretty comfortable with our scaling here. Our existing systems are getting loaded but there's a very clear path from here to get us to more than 10x our current size. Once we start getting that big we'll have to do some more interesting work, but if we get to 10x our current size, we should have enough money that it will be no problem at all.


Finally, the frontend -- our load balancer -- the machine that handles getting all of the user traffic from the Internet to our web servers. We're running a combination of software on this machine, primarily Pound and Perlbal. (Although soon I will be adding Varnish to help with userpic caching.)

Scaling the frontend is easy up to a certain point, after which it becomes really hard. Thankfully that "certain point" is fairly far off. Right now we're at about 25% capacity on this machine -- this is after the doubled load! -- and adding in a Varnish cache for userpics should help reduce that to about 15%.

When we start getting closer to that point I have a few ideas that will help with the load -- notably offloading the Perlbal instances to another machine -- and that will allow us to go up to the bandwidth limit of the machine. We're doing up to about 25Mbps right now and we can go close to 800Mbps before we start to hit capacity on that front.

In short, then, I believe we're in good shape on this front and have a clear path to scaling this out to more than 10x our current load.

Code/other concerns

Honestly, the part that is most likely to bite us is also one of the easiest to fix -- and that's our code. There are certainly inefficient things in our codebase and we will have to address them as they come up. This is also exactly the kind of thing that has led LJ to temporarily suspend ONTD and similar communities from time to time, because that's the most expedient way to get the service back to normal for everybody else while they isolate and fix the problem triggered by the heavy users.

Dreamwidth will have the same policy, too. If the site goes down and it turns out to be because of a particular community or heavy user, we'll take what action we need to bring the site back -- and then we'll work our tails off to get service restored to that particular user/group. I also promise that we will communicate with anybody affected by this and let you know what's up -- you won't sit and wonder what happened.

Open floor!

All that said... any questions? Fire away, I'll answer them to the best of my ability. (Although I will say that right now I'm going to step away from the computer and go make some bread. It's New Year's Eve and I'd like to spend some time with my partner, [personal profile] aposiopetic. I'll check back in though!)

And, if I haven't said it enough, thank you for using Dreamwidth. It's really gratifying to see people moving in and giving things a whirl. We've worked really hard on this site for the past few years -- this is our baby! -- and I'm so excited to share.


Dec. 27th, 2011 05:20 pm
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
I love you, Dreamwidth.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Something I've been meaning to write about, but there's never really a good time, so hey.

One of the best things about building a really awesome foundation on something is that, eventually, you can take a step back and let things continue to go and grow and feel entirely confident that things aren't going to go off the rails without you. Over the past six months I've been reducing my role on Dreamwidth and am recently at the point where I'm really not doing a lot on the site day to day.

I'm still helping out when really needed and I will continue to make myself available for middle-of-the-night site breakages and other problems that need immediate redress. However, I am not taking an active role in the management or development of the project on a day-to-day basis. For any of that, you should talk to [staff profile] denise and/or [staff profile] fu. They're awesome and I have complete confidence in the future of Dreamwidth with them at the helm.

I think that's the salient part.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
There's a bunch of talk going around right now about the whole issue of content security, and trusting the people who host your content and have access to it. I wanted to talk on that for a moment as it's something that is really important to me.

The only people that are authorized to view protected content on Dreamwidth that they don't otherwise have access to are [staff profile] denise and myself. We are the only people with the proper access level. On top of that, it's not automatic -- in order to view the protected content, every time one of us visits a URL we have to edit it and add "viewall=1" to the end of it. It's a very manual process (for good reason). It's also logged -- and I don't know about Denise, but I review the logs regularly, just like every other security log we have.

The second level of access is for people who have access to the production servers that run Dreamwidth. When someone has the ability to log in to our servers, they have full access to the data on the databases and could in theory access protected content. The only people with server access are again myself and Denise, plus our two sysadmins: [personal profile] matthew, who used to work for LJ (before and during Six Apart), and [personal profile] alierak, who I've known for a decade and I trust completely.

That's it. The four of us.

At some point, it comes down to trust. We need the ability to work on the servers, so there are always going to be a set of people who have the ability to see private data. This isn't something that we can feasibly get rid of, either. The data exists on the servers (that's how we can show it to you and the people who are authorized to see it) and we need access to those servers to maintain them. The data isn't just sitting around visible to us, though -- it's tucked away in the database and requires a lot of manual effort to dig out, unzip, and connect to a user account. We never see post content accidentally.

In the end, I think that the best that I can offer anybody is to be explicit about who has access (and what kind of access they have) and to personally watch the security logs. I watch to make sure we don't have unauthorized access to our servers, and I look for unauthorized access to private data as well. It's part of the routine, and it's something I take very seriously. Having dealt with some problems related to this in the past (on other projects, with other people) it's not something I want to see Dreamwidth have to go through.

I'm happy to talk about this, if anybody has any thoughts, comments, or questions.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Happy Birthday, Dreamwidth!

Today is April 30th, 2010. One year ago today (at this very time!), [staff profile] denise and I were running around like some imitation of headless chickens (a weird expression, honestly). We were trying to make sure everything was put together, that all of our ducks were in a row (I'm in a fowl mood apparently), and that nothing was going to go wrong.

The gates opened at 9PM Eastern -- just under five hours from now. We had a lot of users sign up, a lot of Seed Accounts bought, and a great time. We worked hard, we were tired as hell the next day, but we made it.

And now today is DW's first real birthday.

This entire project would not have worked without the tons of effort, time, and love our volunteers have put into Dreamwidth. Thank you, all of you. I am so awed every week when I see how much you all care, how much you contribute, everything. Thank you.

A huge amount of thanks to the people who took a chance on us a year ago, too. You put your trust in a little unproven company and here we are -- a year later, through trials and tribulations, trolls and troglodytes, we are still here.

I'm looking forward to the next year -- and many more!
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
More details are here:

Consider this your official warning! RSVP over on that post, thanks.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
I'm starting to plan a meetup in the local (to me) area, if you're interested, see the details:
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Happy Second Birthday to the Dreamwidth project!

The project was officially named and rolling on a small scale on March 29th, 2008 (that's when the domain was registered). So -- happy belated birthday, us.

Sometimes the project feels so new, I think that we're just in the beginning. We are definitely in the beginning of the project, but we're not so new as all that. We've been public for coming up on two years, actually, since it was announced June 11th, 2008.

Of course, it took us a year to get to the point where we were ready to take on users, so our first anniversary of Open Beta is coming up soon.

And this is me rambling a bit. Marking things down. I need to go back sometime and dig up the original emails that started it all and put them in here so that they are recorded and don't just disappear. There was some interesting discussion back then.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Who's got things to go in the Monday update?
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Who's got the stuff for Monday?
Page generated Apr. 17th, 2014 06:44 pm
Powered by Dreamwidth Studios