#Canonical shipit full#
The world is full of talkers and doers, and in the long haul, people are usually smart enough to figure out which is which. If anyone at Canonical even bothers to respond to this analysis (which I doubt they will), I’m sure it’ll be the same old song-and-dance about how everyone collaborates, and everyone competes, and everyone wins, and the strength of the open source model, and not a fair comparison because Red Hat is so much bigger, and distro wars are bad, and can’t we all be friends, and yadda yadda yadda. In the ONE area where Canonical claims to have the MOST customer focus and the MOST engineering expertise, Red Hat still outproduces them ***16 TO 1***. They’ve done an exceptionally good job with this sleight of hand, but the facts are the facts, aren’t they?
#Canonical shipit software#
Not only that, but they then have the gall to suggest that Red Hat should change its release schedules to make it even easier for them to ride the gravy train (while at the same time making the spectacularly outrageous claim that Red Hat is actually a proprietary software company - LOLWUT?) Canonical has been riding on Red Hat’s coattails for years - not just down in kernel land, but also, we now learn, all the way up to the tippy tippy top of user space. They’ve been very successful at positioning themselves as the Eternal Champion of the Linux Desktop, and positioning Red Hat as the boring old has-beens who long ago abandoned the Desktop fight, and just do backroom server work that Real Linux People don’t care about. They’ve certainly given the impression, over the last several years, of having put a lot of work into GNOME. I mean, I always knew that Red Hat put in a lot of work into GNOME, because I saw it every day - but until now, I thought that Canonical *also* put a lot of work into GNOME. “You’re just mad because Ubuntu’s cooler than you,” the masses would say, and to be fair, there’s always been something to that. Of course, Red Hat engineers, being the upstanding sort of chaps that they are, never said a word about it, because they’ve always been too busy carrying the load - and it’s really never made sense for Red Hatters to complain much about it anyway, because it’s not the sort of discussion that ever benefits the complaining party.
#Canonical shipit code#
One of the most irritating things about working at Red Hat was watching Canonical take credit for code that Red Hat engineers wrote. If you doubt, for a nanosecond, that Canonical is a marketing organization masquerading as an engineering organization, then you’re either an unapologetic Ubuntu fanboy or you’re not paying attention.
I’m just another cranky dude with a blog. Thanks, Dave Neary.Īn upside of not working for Red Hat anymore: I can speak frankly about this kind of issue, since no one really cares what I think anymore. In case you missed it: $SUBJECT is the percentage of contribution to the GNOME codebase. These points should also be considered when writing _str_ or _repr_ for your classes.(Warning: ill-advised rant ahead. The following clues might help you to decide when to use which: str() While str(now) computes a string containing the value of now, repr(now) again returns the Python code needed to rebuild our now object. Let’s move on… > import datetime > now = datetime. In our case passing “‘Python’“ to it works, whereas ‘Python’ leads to an error cause it’s interpreted as the variable Python which is of course undefined. This function takes a string and evaluates it’s content as Python code. With the return value of repr() it should be possible to recreate our object using eval(). > str ( 'Python' ) 'Python' > repr ( 'Python' ) "'Python'"Ī second pair of quotes around our string. Let’s see them in action: > str ( 123 ) '123' > repr ( 123 ) '123'Īlright no difference for now.
But what’s the difference between them? When having a look at the docs > help ( str ) 'Create a new string object from the given object.' > help ( repr ) 'Return the canonical string representation of the object.' Ever wondered what happens when you call Python’s built-in str(X), with X being any object you want? The return value of this function depends on the two magic methods _str_ being the first choice and _repr_ as a fallback.
0 kommentar(er)
