LWN: Comments on "KS2009: How Google uses Linux"

LWN web design

foom — Fri, 13 Nov 2009 01:11:03 +0000

I just noticed the program "Marketplace":

Marketplace... Craig's List. Without the Ugly.
Love Craig's List but hate how painful and ugly it is? Me too. So I made Marketplace. It takes the pain and ugly out and leaves the good stuff in.

I agree with the other comments that LWN could do with some sprucing up. It doesn't really bother me that it's currently ugly, I still read (and pay for) it. But I wouldn't mind it being nicer, either, and it might keep other readers from running in terror.

LWN web design

nye — Tue, 10 Nov 2009 12:40:29 +0000

This idea may be absolutely unthinkable to you, but it is actually possible to appreciate good design without being a sub-literate fool, despite what your prejudices may lead you to feel.

LWN web design

quotemstr — Tue, 10 Nov 2009 12:33:01 +0000

My original point, if I may flesh it out a bit, is that the kind of person bothered by LWN's layout probably won't get much out of LWN's content in the first place. LWN's attraction to me is the deep, literate, and mature coverage, and to a lesser extent, the informative and useful comment section. I couldn't care less how the site looks, and would be just as happy (no, happier) if I could read it over NNTP. Changing lwn.net to pander to the Digg crowd would compromise what makes LWN worthwhile in the first place. Franky, the kind of person who judges a site based on how Web 2.0 it is would find the articles here boring, and would post vapid comments saying so. It'd be an Eternal September.

LWN web design

hppnq — Tue, 10 Nov 2009 12:31:44 +0000

Another cup of Open Source, anyone?

LWN web design

kragil — Tue, 10 Nov 2009 12:06:31 +0000

Again you don't listen. My suggestion: (I spell it out especially for you because you seem to be unable to grasp simple stuff.(Disrespect goes ways))

Get a good web designer that knows modern web design (page layout, usability, style, colours, logo etc.) and have him/her improve the crappy first impression this site makes. That may or may not include rounded corners. I don't know as I am not a web designer as I already mentioned and explained that that was just one tiny technical example, which still does not fit into your brain. All I know is that this sites design (unprofessional logo with green font, annoying flashy ads, black,red or blue text, grey and orange boxes, no advanced CSS etc.) undeniably makes a bad impression, which does not help anybody.
This doesn't have cost a lot. There are a lot of talented young web monkeys out there that don't charge a lot per hour. First thing though is to acknowledge that not everything is peachy.

LWN web design

anselm — Tue, 10 Nov 2009 10:51:03 +0000

This is getting silly. If you can't point to anything specific and constructive that you would actually change to improve LWN.net other than »use rounded corners, they're cool« this must mean that the site isn't so bad to begin with, so I'll politely and respectfully suggest you shut up.

LWN web design

kragil — Tue, 10 Nov 2009 01:11:12 +0000

Well, sometimes you have to spend money to earn it.
And I suggested that you google for CSS capabilities and designs.

LWN web design

kragil — Tue, 10 Nov 2009 00:22:48 +0000

I never visited craigslist until now, but I think the reason for their continued success is the big userbase, even langpop uses CL as a data source. And you could say they have a super minimalistic design (no pics, just standard link colours and nothing else, although for cologne they have a little de for Germany next their name.So they have design. LWN not so much)

LWN web design

anselm — Tue, 10 Nov 2009 00:10:39 +0000

If your resources are limited (as LWN.net's are) it makes sense to stay away from stuff that is essentially eye candy for people who must always have the latest and greatest, and concentrate on stuff that benefits all your readers, like compelling content. If I was in charge of HTML/CSS development for LWN.net, I would consider some changes but they would not in the first instance touch the visual appearance -- I would probably move to a purely CSS-based (instead of table-based) layout to make the site more accessible. I might change some of the visual design but only to improve readability, not to make substantial changes to the layout as it appears. IMHO, such changes would be worthwhile but they would not be changes for change's sake the way you seem to be advocating. (Feel free to suggest anything specific that will actually improve the reader's experience if you can think of something.)

As far as Google is concerned, when the site was new it looked completely unlike all the other search engines precisely because it went back to the basics and presented essentially a logo, text entry widget and search button. In spite of this »conservative attitude« it still went on to become the most popular search engine on the planet. Again, it was the content that made the difference, not the (lack of) bling; people were attracted more by the good results Google produced than they were turned off by the straightforward appearance. Also, in spite of not changing its appearance substantially during the last decade or so, www.google.com isn't likely to go away anytime soon, either.

Finally, the »big stream of money« from subscribers is, to a large degree, what keeps LWN.net going. Jon & co. may, in fact, be very interested in updating their web design but perhaps they can't afford to spend the time or money at this moment. So if you want them to be able to contemplate non-essential tasks like HTML/CSS hacking, instead of whining about how LWN.net will go away if they don't »adapt« you should really contribute to their bottom line by taking out a subscription, which will certainly have a much greater impact than any amount of whining.

LWN web design

quotemstr — Mon, 09 Nov 2009 23:40:00 +0000

most websites that never change and don't adapt have a good change of dying

Yes, but that adaption doesn't necessarily have to come in the form of the latest design trends. Objectively speaking, LWN is perfectly usable. What you're objecting to is LWN's not following web fashion. Not following web fashion hasn't seemed to hurt craigslist, despite the existence of many more hip competitors.

LWN web design

kragil — Mon, 09 Nov 2009 23:26:03 +0000

Again, I never said LWN should work, look or do anything like digg and only mentioned rounded corners as one of the more advanced things you can do with CSS. You can also do gradients, text shadows etc and a lot more stuff. Google is your friend here. I guess you read what you want to read.
I just think a more professional more modern look that appeals to _more_ people (not just digg users) and makes a good impression has no downsides, but a lot of people hate change and want to do and have things the same until eternity. Fine I guess that is how life conditions them in the long run, I just happen to have a less conservative attitude and most websites that never change and don't adapt have a good change of dying, even with the big stream of money you send their way.

LWN web design

anselm — Mon, 09 Nov 2009 16:46:41 +0000

Right. Rounded corners. Rounded corners will definitely make all the difference! Honestly, if you can't come up with better suggestions than this ...

I just had a look at the comments on the Digg article you quoted above and I'm not convinced that encouraging that sort of crowd to come here is something Jon & co. should spend time and energy on. If the web design is what keeps them away then I would surely recommend keeping things as they are.

(Incidentally, looking at the Digg site itself, I'll take current LWN.net over the Digg design any day, thank you very much. Maybe it's just me, but I like my fonts readable and navigation where I can actually find it. Also very incidentally, unlike you I in fact pay LWN.net money every month so they can keep doing what they are doing so well. I wonder how many of the Digg users you revere so much would -- even if LWN.net looked like Digg?)

LWN web design

kragil — Mon, 09 Nov 2009 15:57:26 +0000

I never said anything about coming here for great web design, just about not thinking geocities is still alive.

And I am no web designer, but AFAIK you can do a lot of nice stuff with just CSS (even rounded corners etc.). A lot of small changes done by a professional would certainly add up. And it would still be backwards compatible and no-frills.

Just read a few comments on the link above to look beyond your little bubble.
I don't think a more professional look would be bad for LWN. Quite the opposite.

LWN web design

anselm — Mon, 09 Nov 2009 15:00:03 +0000

In what way is the LWN.net design not »good«? It does what it is supposed to do in a very unobtrusive way -- unlike many of the newer sites. Not chasing after the latest visual fashions does not automatically make its layout, fonts, and colours »bad«. Exactly what about these do you think is keeping new users away?

(Having said that, table-based layout isn't exactly the done thing these days, but you only addressed »layout, fonts, and colours«, not HTML-level implementation, and as far as I'm concerned there's nothing whatsoever wrong with those. Also, registered users can tweak the colours to their own liking, and it probably wouldn't be impossible to allow the fonts to be tweaked, too.)

I'm sure that the LWN.net team will welcome constructive hints as to how to improve the LWN.net »experience« without giving up the strengths of the site, i.e., no-frills Linux info and commentary. For the time being, however, I'd much rather Jon & co. spend their time on giving us the best Linux news possible than chase the newest fads in web design. After all, people come here for the content, not to see great web design.

LWN web design

kragil — Mon, 09 Nov 2009 14:17:21 +0000

True, most current subscribers probably like or don't mind the design.
But it sure as hell does not appeal to new subscribers (in general)
And the general lack of good web design (I am talking good layout, fonts and colours .. not JS, Flash or anything) is probably keeping new contributors and so some extend even new Linux users away.

LWN web design

quotemstr — Mon, 09 Nov 2009 12:59:41 +0000

Good. Dig repellent.

LWN web design

k8to — Mon, 09 Nov 2009 10:32:43 +0000

I for one greatly appreciate the current design.

LWN web design

kragil — Mon, 09 Nov 2009 09:33:44 +0000

This article finally hit digg ( http://digg.com/linux_unix/How_Google_uses_Linux_2 ) and from the comments you can see that LWN does not really appealt to most of the Digg crowd (even in the Linux section).

I think hiring a web designer from this century (new colours, css stuff) could really improve this site. I am not talking lot of JS or Flash, just a newer more modern look.

Kernel hackers seem to complain that new blood is lacking, but for an ignorant observer a lot of stuff seems stuck in 1996.(just compare Rails,Gnome,KDE,etc news and planet sites to what the kernel has .. )

I won't even mention microblogging :)

KS2009: How Google uses Linux

vbeeno — Sun, 08 Nov 2009 13:08:54 +0000

Wow, LInux totally rocks. Always has and always will.

Jess
www.private-web.se.tc

KS2009: How Google uses Linux

jlin — Sat, 07 Nov 2009 21:01:05 +0000

I've read from a conference that Google actually goes to DRAM manufacturers and buys bulk memory chips that failed QA, and makes the ram dimm modules themselves in order to take advantage of scale. For Google, the low price outweighs the troubles of validating the failed RAM chips themselves for salvagable parts.

Perforce

jengelh — Wed, 04 Nov 2009 21:44:44 +0000

Repository size is one issue. Just imagine if all of kernel.org, gnome.org and freedesktop.org (perhaps add in all of XFree86 too for fun) lived in a single repository. Oh and don't forget binary blobs that are popular to be added to corporate repos. Initial clone with --depth=MAX, anyone?

Sure you could split it up, but uh, all too tightly integrated. Should anything go git in a future, I would guess all repositories will start with a fresh slate.

Perforce

mfedyk — Sun, 01 Nov 2009 18:54:58 +0000

You probably want to look at couchdb and the fuse driver for it.

Git it

Holmes1869 — Sat, 31 Oct 2009 04:55:25 +0000

I'm in the exact same situation. Been using it for 3 months now for a personal project (hope to put it up on Gitorious.org someday), and I've just been blown away. "git rebase -i" (I use it a lot since no one else is depending on me) is just amazing. "git add -i" (for committing individual pieces of a file) has single-handedly made me despise using SVN at my day job. I really used to love SVN too.

That being said, I feel that some of the git features will only ever be used by people that take source control seriously. The people I work with check-in code without commit messages, mistakenly commit files that they forgot they changed (or other random files that ended up in their sandbox), and don't ever perform a simple 'svn diff' (or Subclipse comparison) just to make sure they are checking in what they want. Do you think these people care that they can re-order or squash a commit to create a single pristine, neat, atomic commit to fix exactly one particular bug? Probably not unfortunately. I hope to one day work with people that do care.

Appliance kernel source?

cdibona — Fri, 30 Oct 2009 22:25:30 +0000

You guys are killing me, we've had this up The GSA Mirror for years and years. Enjoy!

Chris DiBona

Perforce

lkundrak — Fri, 30 Oct 2009 21:57:43 +0000

Our company's just moving away from subversion, though it serviced us well for some time. As the project grows, the svn merge support is really "worse than nothing." With a development team of ~30 engineers, I am constantly seeing issues like unable to merge after moving a file with a mergeinfo property from subtree merge, wasting considerable time on fixing up mergeinfos after engineers branch off other branches and do cross-branch merges. Moreover, the merge mechanism is different in 1.4, 1.5 and 1.6. Cryptic error messages tends to scare people off a bit too. Squashing all the commits of merge source into one commit in target greatly devaluates certain tools, such as annotate too; which was not an issue when the project was smaller, but gets rather annoying with the history growing.

Perforce

tutufan — Thu, 29 Oct 2009 03:05:29 +0000

> When you start editing a file, it tells you who else has it open.

Wow. I can almost hear the punch card reader in the background. Talk about an obsolete mindset. If I'm editing file X, do I really want to know whether somebody, somewhere, working on some idea that I have no idea about, is trying out something that also somehow involves file X, something that ultimately may never see the light of day? No.

If we get to the point of merging, I think about it then (if necessary).

Appliance kernel source?

dsommers — Tue, 27 Oct 2009 09:13:30 +0000

That's exactly why I would insist on seeing the code ;-)

KS2009: How Google uses Linux

oak — Sun, 25 Oct 2009 19:24:50 +0000

In the Maemo (at least Diablo release) kernel source there are
configurable limits for when kernel starts to deny allocations and when to
OOM-kill (besides notifying user-space about crossing of these and some
earlier limits). If process is set as "OOM-protected", its allocations
will also always succeed. If "OOM-protected" processes waste all memory
in the system, then they can also get killed.

KS2009: How Google uses Linux

Tomasu — Sat, 24 Oct 2009 01:26:57 +0000

2) probably because they actually want some over-commit, but they don't want the OOM thread to go wild killing everything, and definitely not the WRONG thing.

KS2009: How Google uses Linux

dvhart — Fri, 23 Oct 2009 22:13:51 +0000

A couple of thoughts while reading the article.

1) sched_yield with CFS trouble
Does the /proc/sys/kernel/sched_compat_yield flag help? This is the third time I've ran into sched_yield() behavior issues in the last couple weeks, all related to userspace locking. I'd really like to know what we (kernel developers) can do to make this recurring problem go away. Big applications often seem to have need of better performing locking constructs. Adaptive mutexes, implemented with futexes, seem like they could address a lot of this, with a couple exceptions: the spin time is not user configurable AFAIK, the additional accounting, etc. done in support of POSIX seems to make even the uncontended calls into glibc too expensive. A common response seems to be that userspace locking isn't the right answer and they should rely on OS primitives. Unfortunately, as Chris Wright mentioned during Day 1, these developers of empirical evidence to the contrary. I was reviewing some for a different project today, sometimes the performance difference is staggering.

2) Mike asked why the kernel tries so hard to allocate memory - why not just fail to allocate if there is too much pressure. Why isn't disabling overcommit enough?

Perforce

dsas — Thu, 22 Oct 2009 19:17:01 +0000

Subversion 1.5 has merge support, it's not as good as say bzr or git but it's better than svn copy.

Perforce

cmccabe — Thu, 22 Oct 2009 07:38:21 +0000

> What on earth makes people (or companies) use Perforce?

I've worked with perforce, subversion, and git in the past. The three systems all have very different philosophies.

perforce has some abilities that none of the other systems have. When you start editing a file, it tells you who else has it open. You can look at their changes, too.

Both perforce and subversion can check out part of a repository without checking out the whole thing. Git can't do this. Arguably, you should use git subprojects to solve this problem. I've never actually done that, so I don't know how well it works.

Of course, git allows you to work offline, which neither perforce nor subversion can do. git also allows you to merge changes from one client to another ("branch," in git lingo). I've definitely been frustrated in the past by having to manually port changes from one perforce client to another-- even wrote scripts to automate it. What a waste.

"p4 merge" is a powerful command, much more powerful than "svn copy." p4 preserves the "x was integrated into y" relationships between files, whereas svn does not. Imagine a company that has branches for product 1.0, 2.0, and 3.0. It periodically integrates changes from 1.0 into 2.0, and 2.0 into 3.0. In this situation, the relative lack of sophistication of svn copy is a real Achilles heel. Imagine how much pain renaming a file in version 2.0 causes for the hapless svn copy user. Each time the build monkey does the integration from 1.0 to 2.0, he has to remember the files that were renamed. Except that with perforce, the system remembers it for him.

git I think has heuristics to detect this sort of thing. In general git was built from the ground up to do merging on a massive basis.

perforce also has excellent Windows support, a pile of GUI tools, and was about a dozen years earlier to the party. git and svn are catching up with these advantages, but it will take some time.

-delta

cortana — Wed, 21 Oct 2009 23:51:06 +0000

Thanks so much for that. I would have suggested a patch, honest, but I'm super busy at work at the moment... ;)

Presumably git-pull running out of memory would be a server-side issue? And in that case, if you're not running a sensible 64-bit operating system on your server then you deserve what you get... ;)

-delta

joey — Wed, 21 Oct 2009 23:31:44 +0000

Me and my 50 gb git repos thank you for that! But since finding LWN comments
in future is not my strong suite, I sent in a patch to document it on
gitattributes(1) ;)

Looks to me to make large object commits fast, but git pull will still
compress the objects, and still tends to run out of memory when they're
large.

KS2009: How Google uses Linux

cpeterso — Wed, 21 Oct 2009 22:46:38 +0000

If Google simply made their (non-proprietary) patches or git trees available to the public, then other kernel developers could adapt (or be inspired by) Google's work to the mainline kernel.

KS2009: How Google uses Linux

dany — Wed, 21 Oct 2009 22:21:51 +0000

thanks for report, as always its interesting reading

Perforce

ianw — Wed, 21 Oct 2009 22:02:07 +0000

Same inside VMware, another big user of Perforce. We've got an increasing number of developers using git-p4 wrappers, and even now tools using it - the git based pre-submission build testing stuff evens twitters at @vmwarepbs if you submit something that breaks the build :)

Although everyone always talks about getting rid of it, there is so much build, QA and release infrastructure built around it, I can't fathom it could ever happen. But, using git wrappers, us developers can pretty much forget that it's even there :)

KS2009: How Google uses Linux

jmm82 — Wed, 21 Oct 2009 21:57:55 +0000

I believe the reasons were outlined why they are not contributing code into the kernel.

1. They are not using kernels that are close to linus git head.
2. Some code would not be wanted in the mainline kernel.
3. Some code is not good enough to get into the mainline kernel.
4. They don't want to have 30 people saying the code will only get in if it does this. Aka. They don't want to make it support the features they are not using.
5. Some code is proprietary and they want to protect the IP. As was stated above as long as they are not distributing the code the changes are their property.
6. A lot of there patches are code backported from mainline, so it is already in the kernel.

I think moving forward that you will see Google have a few developers working on mainline to try and influence future kernels because it will be financially cheaper to carry as few patches as possible. Also, I feel they will always have some patches that they feel are too valuable IP to gave back and will continue to maintain those outside the mainline.

Git it

man_ls — Wed, 21 Oct 2009 21:11:14 +0000

Git is lightning fast (at least for code, I don't know for binaries), it's distributed and (surprise surprise) it's addictive! The cycle of 'commit, commit, commit, push when you're ready' is amazingly productive. I'm using it in my first project as single developer and I wouldn't change it for anything else I've used -- including cvs, svn, ClearCase, AccuRev and a few others too shitty to mention.

KS2009: How Google uses Linux

maney — Wed, 21 Oct 2009 21:08:30 +0000

You imply that denser chips will cause higher error rates, but that is not what they found:

We studied the effect of chip sizes on correctable and un- correctable errors, controlling for capacity, platform (dimm technology), and age. The results are mixed. When two chip configurations were available within the same platform, capacity and manufacturer, we sometimes observed an increase in average correctable error rates and sometimes a decrease.

There were other, also mixed, differences when comparing only memory module sizes, but that mixes together differences in chip density and number of chips on the module - and quite possibly chip width as well.

The best we can conclude therefore is that any chip size effect is unlikely to dominate error rates given that the trends are not consistent across various other confounders such as age and manufacturer.

Which, I think, summarizes decades of experience that refuted various claims that the ever-shrinking memory cells just had to lead to terrible error problems. I may still have an old Intel whitepaper on this from back in the days when chips sizes were measured in Kbits.