Torvalds: Standards are paper. I use paper to wipe my butt every day.

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

by statictype • 15 years ago

330 175 15 years ago

bugzilla.redhat.com

yuvadam• 15 years ago

You gotta _love_ Linus' writings.

dtby• 15 years ago

I do wonder on what basis I must _love_ his writings.

I'm not a Linux guy, so I am out of the loop. What makes these writings so lovable?

esmevane• 15 years ago

The nature of the Father of Linux being, in essence, an enraged (often insightful) crusader is just a point of pride for a lot of people who know about him and like Linux.

rjbond3rd• 15 years ago

He's straightforward.

ascendant2• 15 years ago

As the originator of the OS and still working at a low level, it's nice to see him (A) care about the user experience all these year later and (B) cut through other people's bullshit the way a lot of us wish we could.

jpk2• 15 years ago

I would also include that he's furiously pragmatic. Which stands in contrast to other Free software personalities, who are often furiously idealistic.

irfn• 15 years ago

indeed. this one is my fav. http://thread.gmane.org/gmane.comp.version-control.git/57643...

yonilevy• 15 years ago

I actually find it to be really bad, and I'm not the only one -http://www.informit.com/guides/content.aspx?g=cplusplus&...

srram2• 15 years ago

While I agree with his focus on users, he has passed up a valuable coaching opportunity and probably antagonized a whole bunch of developers. He turned a potential coaching opportunity into a pissing match. Ridiculing volunteers on a open source project is inappropriate, irrespective of whether the opinion of that person was right or wrong.

gommm• 15 years ago

If you look at the history, the comments at the beginning were much less abrasive. It's only after the discussion continued for a long time that he started being more aggressive in his comments.

vacri7• 15 years ago

he has passed up a valuable coaching opportunity

???

In the comment I read, he goes into detail about why it's wrong.

His next comment that starts "Bullshit." goes into 500 words of coaching.

He is backing up his arguments with developer-level people here, not newbie coders who are still figuring out how an array works.

mjs• 15 years ago

I find it interesting that Linus seems to have originally come across this particular bug report as a user; he, too, was having a problem with Flash player:

https://bugzilla.redhat.com/show_bug.cgi?id=638477#c8

"I see this as well. Sounds like clipping or some really bad sample rate frequency conversion."

(It's only later that it becomes clear that this is due to a glibc "regression".)

acqq• 15 years ago

For the long history of how some glibc developers are enjoying to make more problems to the users see also:

http://www.tuxradar.com/content/debian-ditches-glibc-eglibc

I consider all this a real attitude problem.

tptacek4• 15 years ago

The first bit of evidence linked to by that article is glibc's maintainer complaining that he's being asked to improve the strfry() function, after a detailed technical analysis. If you don't know what strfry() is, that response does look unreasonable. But he's right! strfry() is, literally, a joke function.

famousactress• 15 years ago

I think it's awesome how focused someone who works on the very lowest level of the OS remains so focused on users, and their experience.

j2d2j2d2• 15 years ago

You might also enjoy this "USE KDE!" rant from a bunch of years back.

http://tech.slashdot.org/story/05/12/13/1340215/Torvalds-Say...

sudonim2• 15 years ago

I wonder what he thinks 5 years later? It seems like Gnome is the default on most distros. Are the attitudes he describes still influencing Gnome?

hyperbovine• 15 years ago

Seeing the forest instead of the trees is a common trait of successful people.

bonch• 15 years ago

Linus is a patch shepherd. It's his job to see the bigger picture.

chuhnk• 15 years ago

"Bullshit. You clearly don't know what you're talking about."

Tells it like he sees it. I'm not going to argue with the man. He makes some good points. The user really doesn't care what the underlying changes are as long as everything continues to work, in this case it does not. Reading back through the comments its clear Linus makes great suggestions which are left unheard.

I like comment #222 https://bugzilla.redhat.com/show_bug.cgi?id=638477#c222

"Breaking existing binaries with a shared library update IS A BAD THING. How hard can that be to understand? If you break binary compatibility, you need to update the library major version number."

e40• 15 years ago

This hit the product I work on and I agree 100%. We had to scramble for days to fix this. (Find a test case, diagnose it, make the fix, release a patch.) It was a pain in the ass. At least the solution was a 1 liner.

xilun02• 15 years ago

explain how you fix any bug or change any implementation by still respecting your side of a contractual interface without breaking said "binary compatibility" when using this broken definition of "binary compatibility"

exposure of a random proprietary software bug written by morons does not imply breakage of "binary compatibility". some free software developers have no time to test their standard compliant library against all crappy proprietary software ever written under the sun. if that makes you sad, at least you are free to modify the fucking library for your own little use case, or even to fork the library and maintain your fork with an explicit policy of never ever changing externally observable behaviour (probably meaning you won't make any change to said library (other than in comments) if you REALLY apply this rule...), which happily glibc never had and hopefully never will have.

ot2• 15 years ago

These fights between "specs lawyers" and "pragmatic" programmers are painfully frequent. Reminds me of the ext4 controversy on the out-of-order metadata synchronization.

Linus himself has already expressed his point of view many times, for example here (http://www.h-online.com/open/features/GCC-We-make-free-softw...):

> Torvalds has his own take on this, which is that "For some reason, compiler developers seem to be far enough removed from 'real life' that they have a tendency to talk in terms of 'this is what the spec says' rather than 'this is a problem'."

I couldn't agree more.

bmj• 15 years ago

Agreed. We have to produce a lot of paper doc in my domain, and in our bug base, there's a section dedicated to spec bugs. Just cos it's in the spec doesn't make it right.

kabdib2• 15 years ago

And the spec may be right, but it's still the wrong thing to do.

Applications are complex, fragile things. If you care about keeping them going over time, you wind up kowtowing to a lot of workarounds. Welcome to the software industry.

The attitude of "I can change library Z, be spec compliant and still sleep at night even though the change took half an industry down" might be /correct/ but it is not going to retain customers. Do it enough, and you'll see users flee.

lallysingh• 15 years ago

You can be a hacker or a lawyer, not both.

genera• 15 years ago

Linus makes fine points, but it's asinine to say that standards don't matter. His entire contribution to the world could not exist without them.

exch2• 15 years ago

I couldn't agree more with this.

I may be overdoing it a bit here, but personally I don't agree with Torvald's p.o.v. at all. While user experience is obviously important, allowing mistakes like this to go unchallenged by simply providing a work-around just encourages people to write broken software. Specs exist for a reason. Ignoring them is not it.

I do this in my own software as well. If a user files a bug because input X fails to process as expected -- and it turns out his/her input does not meet the spec -- I do not supply a fix. Even if his/her supplied input is widely used in 'the wild'. While this alienates a considerable user base, I refuse to be part of the problem.

radagaisus• 15 years ago

um, good luck with that.

ascendant2• 15 years ago

Do you at least attempt to show the customer the error of their ways?

simias• 15 years ago

Myself I would go for a compromise. Flash's behaviour (using memcpy when then mean memmove) is definitely faulty, and it's not an obscure C undefined behavior either, I'm sure any C tutorial worth mentioning has "if you want to copy overlapping regions of memory, use memmove" somewhere in the middle. I'd just fill a bug on adobe's bugtracker, tell them "we'll keep the current for X months, but then we'll switch to a new implementation, so if it still breaks it's up to you". With X being a reasonable enough lapse of time.

By the way, if flash was open source it would probably be a one line patch to fix the issue, but it's not, and I wouldn't blame the fedora/glibc devs for that. Breaking things because "you can" is no good policy, but it doesn't mean you have to be backward compatible for ever, that's what being realistic is about.

nadahalli• 15 years ago

I can see the moral hazard side of things; but Linus does have a point.

There has to be great benefit from changing the implementation of memcpy for it to be worth it. And broken flash is an obvious negative. And across the said thread, there is argument that the new implementation might not be the best as well. So, with two negatives and no obvious positives why do it at all?

protomyth• 15 years ago

If early web browsers has stuck to the spec and rejected all "bad" inputs, then web probably would have been a better place today. Sometimes the user's interests are in the future not in the now.

dedward• 15 years ago

Scoped properly, he's entirely correct. The user doesn't care about standards. The user cares that STUFF WORKS. Standards serve a purpose - but standards are guidelines. Adobe & Redhat had no contractual obligation I assume, so really it's up to either of them to fix the problem - and in fighthing about who did what wrong is pointless if a couple lines of code ora few hours of work are all it will take to make things work.

In this particular situation, the standards were not helping get things up and running, right?

aidenn0• 15 years ago

Are you referring to POSIX? Because if so, you should know that it is a shining example of a worthless standard and that most unix programs rely on unspecified behavior far more than this easy-to-make flash bug.

tluyben2• 15 years ago

Although I like the attitude on some level and in this case he is obviously right, the problem with it is that our (and others I know) programmers feel like cowboys after reading HN posts like this. 'Ruby master bla says I don't need comments and documentation man!' 'Testing is sooo 00s; we use our brains!' 'Specs and standards are paper, read Torvalds; he uses that in his watercloset! Yeah he isn't talking about specs, but those are paper too!'.

abdd0e78• 15 years ago

Linus himself has said that he has an ego the size of a small planet.

SoftwareMaven3• 15 years ago

Ego, properly applied, changes the world.

raquo• 15 years ago

Sometimes even to the better.

bcl• 15 years ago

I like comment 132 better - https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132

rwmj2• 15 years ago

Good, although that's also an argument for ditching C and using a decent high level language instead.

sriramk• 15 years ago

The upstream glibc bug is worth reading too. My favorite bit 'Everyone is interested in using the code idiots write'.

javert16• 15 years ago

A spec is a contract between programmers, and in the long run, following specs is good for users. Letting Adobe ignore specs and then bending over backwards to accomodate them doesn't seem like a good policy.

And even if following the spec weren't better for users in the long term, it is technologically superior, and Fedora is free to choose the technologically superior alternative over pleasing the masses if they want. Despite what Linus suggests, there is no Ten Commandments of software that dictate the rules here.

I guess Linus could have used this opportunity to convince a naysayer like me why I'm wrong, but instead he was just insulting and didn't address the real points at all.

(And FYI, I'm a diehard Linux user)

linuxguy• 15 years ago

Quite frankly, I find your attitude to be annoying and downright stupid.

How hard can it be to understand the following simple sentence:

   THE USER DOESN'T CARE.

jpr3• 15 years ago

How hard can it be for Adobe to write standards conforming code?

The user doesn't care, but professional software developers, which I assumes Adobe's developers are, should make it a priority to follow the relevant standards.

Silhouette• 15 years ago

The trouble with this whole argument is that while the user may not care today, things like standards and defined interfaces are all about keeping things working tomorrow. Your user will surely be just as upset at something breaking tomorrow as they are today, and it's increasingly likely that such breakages will (a) occur and (b) cost more to fix, the longer you implicitly support deviations from the standards.

SoftwareMaven3• 15 years ago

So, glibc changes, breaks adobe, and it is adobe's fault? Even if adobe was relying on bad behavior, it was glibc's bad behavior it was depending on.

These are the kinds of problems that finally convinced me to move from Linux to OS X. I get the Unix without the egos (just the fanbois, but I can usually ignore them ;).

kjhgfghjm• 15 years ago

Adobe had a bug which worked because of a Bug in memcpy(), the bug was fixed and Adobe's code broke.

win95 had a similar one with the game Civilisation, they actually put code into win95 to detect the game and change the way the OS worked - doesn't sound like a good solution

javert16• 15 years ago

it was glibc's bad behavior it was depending on

Hmm. Well, I was assuming that glibc was following the spec all along but just changed some implementation detail that mattered because Adobe wasn't following the spec all along.

I think there's an argument to be made that the way an API is implemented is an implicit contract that ought to be upheld. But that's not the arugment I see being made.

Anyway, this level of detail is below the scope of the "specs vs pragmatism" debate that's going on.

jpr3• 15 years ago

> Even if adobe was relying on bad behavior, it was glibc's bad behavior it was depending on.

Wasn't it implementation details it was relying on? Isn't NOT relying on implementation details pretty much the basis of good software engineering?

jseliger• 15 years ago

So, glibc changes, breaks adobe, and it is adobe's fault?

This reminds me of Joel Spolsky's article, "How Microsoft Won the API War:"

"There are two opposing forces inside Microsoft, which I will refer to, somewhat tongue-in-cheek, as The Raymond Chen Camp and The MSDN Magazine Camp.

Raymond Chen is a developer on the Windows team at Microsoft. He's been there since 1992, and his weblog The Old New Thing is chock-full of detailed technical stories about why certain things are the way they are in Windows, even silly things, which turn out to have very good reasons. . .

The other camp is what I'm going to call the MSDN Magazine camp, which I will name after the developer's magazine full of exciting articles about all the different ways you can shoot yourself in the foot by using esoteric combinations of Microsoft products in your own software."

He thinks the MSDN camp won, and that's bad, and he contrasts with, say, Apple in historical times:

"A lot of developers and engineers don't agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It's why so few applications from the early days of the Macintosh still work. For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple's official Bible of Macintosh programming, there was a tech note saying "you can't do this," they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn't run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.

To contrast, I've got DOS applications that I wrote in 1983 for the very original IBM PC that still run flawlessly, thanks to the Raymond Chen Camp at Microsoft."

The thing is, Apple is still mostly like that. Want the new hotness? Upgrade. I've been using OS X since 2004 and have trouble remembering all the stuff that broke because of OS updates (NetNewsWire and printing were particularly common). I don't know if it's because of the MSDN camp in Apple, but I do find it ironic that you cite things breaking as a reason to move to Apple. There are plenty of them, but I'm not sure that's one.

pmjordan2• 15 years ago

It's always a trade-off, but in this case the cost is minimal. If your program is limited by the speed of memmove/memcpy(), and you absolutely must copy (rather than alias, or whatever), you probably want to use a 128-bit aligned, widely unrolled SSE copy or something like that. That is, take advantage of the constraints of your precise situation. You can't do that with an API as generic as memcpy().

ssp• 15 years ago

In newer versions of glibc, memcpy() does take advantage of SIMD instructions if they are avaialble. It works something like this:

The memcpy() function is marked specially in the ELF file. On the first invocation, the dynamic linker actually calls the function and then takes the return value and treats it as a function pointer. This function pointer is then used for linking, so that subsequent invocations will call that pointer instead.

The memcpy() function in glibc then simply checks which SIMD extensions are available and returns a pointer to the appropriate real memcpy to use.

fleaflicker• 15 years ago

That's a deceptive title. The real point is more important (but less sensational):

Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.

javert16• 15 years ago

A spec is a contract between programmers and in the long run, it's better (for users and programmers) to follow specs and expect others to follow them, rather than to let others break them willy-nilly and just bend over backwards to accomodate.

Oh, but I guess since this point requires actual thinking to understand, it's not in the realm of reality...

nddrylliog• 15 years ago

So what, if the spec says "jump off a cliff", you'd do it?

Linus explains in-depth why the distinction between memcpy and memmove is arcane and useless nowadays, shows how glibc's over-engineering crap actually hurts performance instead of helping, and that being a tight-ass (ie. doing /more/ than the spec) just makes the situation worse for everyone.

Are you all seriously thinking that Linus doesn't know about performance? He's not Miguel, dammit...

fauigerzigerk• 15 years ago

Seeing this purely as a spec v pragmatism issue isn't going to get us anywhere. There is just no way around looking at each case individually. There are specs that are pie in the sky, outdated, flawed compromises or reflections of vested interests. But there is also a huge amount of lock-in and lost productivity resulting from lack or disregard of specs (e.g IE6). I see no way to be principled on that one.

mrcharles3• 15 years ago

I understand your point and the purist programmer in me agrees but maintaining compatibility in the face of horribly broken software is how Microsoft managed to get on top with windows. If you've ever spent time reading The Old New Thing ( http://blogs.msdn.com/b/oldnewthing/ ) you'd realize the lengths MS went to to make sure that even when they improved things, they didn't break bad software, and how much that meant for people adopting the platform.

Seems to me kind of an important thing to recognize in this kind of discussion.

gersh• 15 years ago

Contracts are written and signed. Specs should wikied.

azernik2• 15 years ago

This ideal is completely irrelevant here - the change Linus and many people are asking for here (aliasing memcpy to memmove) explicitly does not violate the spec; all the spec says is that memcpy is not guaranteed to work when the memory segments overlap.

The conflict here is between going above and beyond the call of the standards and in so doing encouraging expectations of that extra functionality in all software, or implementing only the bare minimum specified by the standards and in so doing breaking software as actually written. Given that this change involved literally checking for the relation between the source and destination address, and copying upward in one case and downward in the other (in so doing, implementing a function which is also required in the standard) adding this functionality to the de facto standard does not significantly increase the barrier to entry for new developers.

I think the ideal solution would be a note in the standard hinting that memcpy can be implemented with memmove, or even better, a deprecation of memcpy in favor of memmove with memcpy being in the interim aliased to memmove, but standards changes are always a pain.

d0m2• 15 years ago

That is something I don't like about Linus. He's so aggressive when he speaks; it's insulting. Explaining to the guy the good attitude to have toward backward compatibility and "not my problem" thing, is totally great. However, doing it in a so harsh tone is just plainly aggressive and useless. In fact, I'd argue that it is even less than useless as if someone talked to be like that, I'd be even less reticent to try to help. Add to this the fact that Linus, being well known and respected, simply demolished him. It's like if I kicked my little 12 years old cousin' ass in front of everyone to make him understand that we he did wasn't right. Good job Linus. I feel like posting on this forum now.

sudonim2• 15 years ago

I read Linus' response as directed at people in the thread in general in addition to the previous poster. The "not my problem" attitude is pretty common in the world. In OSS, it seems even more important to be flexible in order to achieve something good for an end user.

How should Linus have addressed the other guy?

antipaganda• 15 years ago

You've got to understand that it is very hard for highly technically proficient people to be nice to everyone. For someone at Linus's level, a LOT of time is spent answering what seems like the worst kind of stupid questions.

This causes massive compassion fatigue. Take that into account, and it becomes clear that Linus is not as big an asshole as you think.

st3fan• 15 years ago

That is something I don't like about Linus. He's so aggressive when he speaks; it's insulting.

It might also be a european thing. We are more direct. Less talking around the issue at hand.

VladRussian2• 15 years ago

He wasn't insulting. Absence of ass kissing isn't an insult.

>In fact, I'd argue that it is even less than useless as if someone talked to be like that, I'd be even less reticent to try to help.

you sound like you're an ass with overgrown ego.

In general, one chooses whether to get things done or waste the time on gentle handling of ego of the people who can't control their own ego. It is a great boon for humanity that Linus has been choosing the former.

vacri7• 15 years ago

Growing a thick skin and dealing with a curt reply allows information to flow faster. All Linus is doing here is setting the bar. Doing it in flowery everyone-wins language is more time-consuming and the longer you communicate on the web, the more you realise that frequently it's just not worth the time drain. The attitude Linus is commenting on is something he's known for railing against for a very long time.

If you're trying to make a world-class product, you can't afford the time to wrap all comms with your developers in niceties - you need to define where you stand and what's expected in solid terms.

Also: given his thorough explanations that go along with the chiding, I'd much rather be on a forum that has that kind of poster.

andos• 15 years ago

I remember this bug report. Since October 2010, Linus has posted a "me too" reply, then helped pinpoint the issue, then explained why shifting the blame to Adobe is wrong, then provided a workaround for everyone, then ran a benchmark proving the new memcpy code is crap, then helped people having issues with his workaround, and then finally went agressive towards Andre Robatino, whose previous comment is simply daft.

abdulla• 15 years ago

Actually, that's what I like about Linus. I find it humorous, but I also appreciate a "no bullshit", direct approach. He has it in spades, and he backed up his assertions with hard data.

xpaulbettsx• 15 years ago

I absolutely agree that Linus is really aggressive in this example. But in this case, I think it's warranted because the general point he's making is so important: if Linux is to move forward as an OS, this attitude of "It's technically wrong, we don't care who we break" needs to die - it's helping nobody.

DougBTX• 15 years ago

Both are bad, but I prefer Linus's up-front aggression to the passive aggressive tone of the person he is replying to.

kragen3• 15 years ago

It's true that I don't find myself particularly inclined to post on lkml — even though people were polite to me there when I was being kind of an ignorant asshole, I feel a bit intimidated by the brusqueness of the inner circle.

But I don't think I'm really in a good position to advise Linus on how to manage an open-source development community. Linux seems to be running at a high level of average competency despite the occasional hostility. Who am I to say that the hostility is dispensable? I'd like to believe it is, but I want to see an existence proof.

guan• 15 years ago

Linus: “I (obviously) always compile my own kernels”

DeusExMachina• 15 years ago

Going down the thread I found this little gem in one of Linus' replies:

Why? Because _users_ are the only thing that makes software useful. Software isn't useful on its own. You cannot say "this is the right thing to do" unless you take users into account.

ximeng• 15 years ago

Upstream glibc bug here:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518

Assigned to the inimitable Ulrich Drepper, who comments:

"The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation."

CamperBob2• 15 years ago

"The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation."

Sounds like Drepper needs to read the standard C library spec (or else there's a human-language barrier at work here). It is not incorrect to map memcpy() to memmove(). ("Be conservative in what you send, and liberal in what you accept." -- Postel)

Can anyone imagine this debate happening inside Microsoft? This is why they win.

xilun02• 15 years ago

sounds like you misunderstood what Ulrich wrote

mitchellh• 15 years ago

I wanted to note that Ulrich Drepper has proposed a way around the issue, and clearly said at the end "I'm happy to entertain a patch to this effect."

When I first read the parent comment it sounded as though Ulrich immediately shot it down, which he did not. (Note I'm not blaming the OP of the parent comment for this, I am just trying to help future readers from making the same mistake I did)

While he is not immediately agreeing with what Linus proposed, at least it is progress.

dendory• 15 years ago

Am I the only one that finds it amazing that in 2011 a mainstream Linux distribution like Fedora is still having issues playing YouTube videos? I mean... Linux on the desktop? wow...

code_duck• 15 years ago

Yes, you're probably the only one thinking that, because the idea that there is a problem with Youtube and Fedora is based in an inaccurate reading of this article.

He said Youtube worked fine. It was compared to as a control. The problem was with some other site using Flash.

intellection• 15 years ago

Technical Aggression.

I prefer more people standing against intransient word & law. (Much is called Standards, or Rights.)

Codes hold you.

Our support systems could allow critical viewpoints better.

marshray• 15 years ago

Keep in mind the specs were written to standardize the behaviour that existed at the time: there were implementations of memcpy that worked a bit faster because they didn't have to test for overlapping regions. That's why there's a separate memmove function in the first place.

So people saying that memcpy should work like memmove are really the ones advocating for changing a spec that is currently quite explicit.

Enabling this type invalid behavior from app code is a classic example of introducing dependencies on undocumented behavior. Over time these dependencies accumulate in complex systems with the resulting effect of increasing software incompatibilities, not reducing them.

Confusion• 15 years ago

Is this submission a deliberate attempt to make Linus look bad? The title is not at all what his comment amounts to; it could be removed from comment post without changing the meaning. I don't doubt you can find a multitude of quotes of Linus in support of various, official or pragmatic, standards. He was just polemizing.

statictype• 15 years ago

It wasn't an attempt to make him look bad. I think many/most people here would agree with the sentiment about standards vs actual usage. And that line was delivered with classic Linus style - blunt and with the subtlety of a chainsaw. That's why I chose it for the title.

rcthompson• 15 years ago

So, did anyone try out the workaround in comment 55? I tried it just for fun, but Flash already doesn't crash for me, so I didn't see any difference.

wazzupflow• 15 years ago

Interesting; i wonder why more people don't get into Linux hacking.

binspace• 15 years ago

Now we know Torvalds is regular.

vorg• 15 years ago

Specs are great: Java and Scala both have specs. Not having a spec can be OK if the language designer doesn't change things too often, and announces it well in advance when they do, e.g. Python.

What's worst is, say, when the language "Product Manager" leads a standardization committee that hasn't done anything for 7 years, yet often changes the language implementation overnight so code samples in other people's books and blogs no longer work.

pnathan• 15 years ago

What language is that?

zeynel1• 15 years ago

"Standards are [just] paper."

He misunderstands how the world works. Standard is not just paper; standard is the thing. From this site: http://science1.wordpress.com/2007/04/26/matter-does-not-exi...

    For physicists Newton’s atomic materialism is blinding. 
    It will take many generations of humans to perceive that 
    standard is the thing. There is no “physical” world  
    other than standards and density differentials.

rch• 15 years ago

I don't use Flash on Linux.

But! what's interesting is how much I dislike the first sentence of comment 133.

s3graham3• 15 years ago

Kernighan & Pike:

    The ANSI C standard defines two functions: memcpy, which
    is fast but might overwrite memory if source and destination
    overlap; and memmove, which might be slower but will always
    be correct. The burden of choosing correctness over speed
    should not be placed upon the programmer; there should be
    only one function. Pretend there is, and always use memmove.

Shucks.

Also, static linking.

known• 15 years ago

Popular == Standard

srram2• 15 years ago

an analogy to the web: Quirks mode is a good thing

Torvalds: Standards are paper. I use paper to wipe my butt every day.

Related Stories