You'd be slightly more convincing if you extended the effort to use google yourself and give us a URL - since you apparently know what you're looking for, you can find it much faster than we can.
Alternatively, what happens is that I search google and find someone's blog entry on BSA-MS-USmarshal-guns, which turns out to be nothing remotely connected to reality. I come back here, respond and say "No, this story is bullshit, see?" You can simply respond and say "No, that's not the story I mean."
Well if you're not completely talking out of your arse, GIVE us a pointer to the specific story you mean. Or if you weren't referring to a single incident, find a story on the indicident that best supports your point (and perhaps pointers to some of the others to back up your insinuation that it's happened more than once).
Because, quite seriously, even in a country with as corrupt a legal system as the USA, I find it difficult to believe that a judge would be willing to disrupt a school's activities for a BSA fishing expedition.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 3, Interesting
Shit it's hard to handle appropriate levels of contextual quoting in slashdot-HTML - at least for this long a post *wry grin*.
Most commercial companies have to deal with customer information privately and that means restricting access to versioning systems, bug databases, trouble tickets, and code comments.
And that's fine - Apple is well within their rights to do that. But doing that makes it a hell of a lot harder to consider Webcore a genuine open source project.
WebCore is as open as any open source project, [...]
As open as a project like KDE, which has a completely open source control system, a wide array of open and searchable development mailing lists, and an open bugtracking system? No, I though not:-). See below.
Bullshit. WebCore is an open source web engine and there are even several new open source browsers based upon it [... ]
You misunderstand my point. I didn't say that Webcore wasn't under an open source license, nor did I suggest that Apple was violating the license in any way.
What I did say was that Apple wasn't running Webcore as an open-source project. A serious OS project should first and foremost have the source developed in an open and freely accessible source control system (though this is not an absolute - many less active OS projects can achieve much the same result with infrequent tarball releases, mainly because updates to the project are infrequent). Less important, but also good, are openly accessible development mailing lists (though again there's some degree of variation here - some projects have a closed "core team" list - but the vast majority keep all lists open). An open and freely accessible bugtracker is also a big plus (though again, there's a fair amount of scope for restricting access to important security-related bugs, as does the Mozilla project with Bugzilla).
Regarding the different priorities between Webcore/KHTML:
Actually I think this is the major problem.
Well, it certainly seems to be a big part of the technical problem:).
That's funny I heard the acid test patches were broken up into small chunks and had comments specifically for the KDE team telling them what applied to what as far as the codebase was still the same.
As far as I'd heard, that was a case of too little, too late and I seem to recall another KDE dev suggesting that Hyatt only did it because he (the KDE dev) dared him to (as they'd been asking for lightweight atomic patches for ages with no response). I hope that's wrong and Hyatt is genuinely trying to help the KHTML project - it certainly looks as though he is, going by his blog.
Re: a comment I made about the Apple devs not being willing to answer question or explain changes:
Got any source to back that up?
Actually, no. Dammit. I thought I'd seen a couple of references on the KDE dev blogs regarding the Apple Webcore devs being "unresponsive" to requests for information, but I can't find those references now - I might even have misremembered them. I hereby withdraw that comment.
Well you certainly are opinionated, but I don't think you're as informed as you seem to imply. WebCore is a thriving open source project with numerous new browsers for both OS X and Linux based upon it.
You're dead right on the opinionated count:). And I'm sorry, I didn't mean to imply I was that well informed:).
My main objection to the "Webcore is a genuine open source project" is covered above - the lack of an openly accessible source control server is a bit of a deal-bre
I'm rather intrigued/puzzled by your comment that "nothing constructive" could be done unless these two disparate projects were using the same source control software.
What on earth makes you think that it'd be any easier to merge changes from one CVS tree to another (different) CVS tree than it would to merge changes from a Perforce tree to a CVS tree (or indeed a Perforce tree to a Subversion tree, as KDE recently converted to Subversion).
Even though this is a kind of a pointless diversion in any case, because Apple aren't providing the KHTML devs (or anyone else) with access to their source control system.
And regarding your PS.... um, well, I don't know any of the KHTML developers personally, but if I were one of them I'd find that comment quite offensive (on several levels).
Well, you see, this is the point - the KHTML devs, from what I've heard, don't really give a crap anymore about what's happening with Webcore. It's a significantly forked project, and practically speaking it'd be more work than it's worth to try to (a) comprehend the Webcore changes, (b) extract those changes, and (c) port the changes back into KHTML.
IIRC, one of the KHTML devs said, quite bluntly, that it'd be easier and quicker to write the damn thing themselves than to try to port features from Webcore.
The KHTML people are probably quite happy with the way the code is licensed - people have the freedom to use and modify the code, and they also have the freedom to contribute or NOT contribute back to the parent project. Apple chose to not contribute, which is fine.
But (and this is really the core issue) that means they really shouldn't pretend that they are contributing.
That, I believe, is what really shits the KHTML developers.
(As an aside, I have no idea what this "CSS stress test fix" is that you're referring to. Link? If Apple really have made an actual genuine contribution to KHTML, I might have to slightly revise my opinion of them)
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 5, Informative
I'm not sure, what exactly did the KDE guys do to help Apple? Did they help them to incorporate the code into their Webcore fork of Konquerer?
The KDE project's CVS (and now Subversion) source control tree is totally open and accessible to anyone (including Apple), has always been that way and will always be that way. Also, the general convention (as I understand it) on large open-source projects like KDE (and especially so on core library components) is that code changes should be made in small, distinct, atomic blocks - with a meaningful commit comment to help comprehend the change (and so the changes can be easily rearranged and merged into, eg. a different branch).
This kind of system makes it relatively easy for the Safari/Webcore team to cherry-pick KHTML changes that they like. Though I have no idea how much they've done this, or even if they've done it at all - for all I know they've taken nothing from KTHML since starting Webcore.
But even so, the existing CVS history helps to understand historical design decisions, and indeed can be helpful in all sorts of subtle ways.
Now, conversely, Apple with Webcore. The KHTML team have no access to the Webcore source control system (it's not being run as a truly open open-source project, even if it is under the LGPL). The KHTML team have (AFAIU) only limited access to the Webcore bugtracking system, with some bugs not visible at all. From the story: "[KHTML] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code."
I think it is unlikely that Apple is going to change versioning systems to make the KDE team's job easier,
Whatever Apple uses for a source control system is utterly and totally irrelevant. What is relevant is that their source control system is not publically accessible. You can't see changes as they're made, you can't track the development trunk. All you can do is take the occasional slabs of code that they release - and the whole point is that that makes it difficult to port interesting code changes into the KHTML codebase.
Added to which, the Safari/Webcore developers have entirely different (ie. commercial) priorities to the KHTML project. The KHTML team are prepared to take more time and do it right. The Webcore team are not - so they're more likely to use kludgy, lower-quality hacks that are simply unacceptable to the KHTML team.
And the Apple developers have done another thing which makes things even more difficult for the KHTML devs to use their changes - they're using significant closed-source functionality from Mac OSX system libraries... thus building in a dependency to a closed library. Which makes it even harder to work out what's happening when Webcore makes a call out to an external library to accomplish some vital task.
Maybe if the KDE developers asked for more granularity with the patches the Safari team would be willing to accommodate them.
Wow, you really haven't read any of the background on this at all, have you? The KDE/KHTML team did ask (many, many times), and the Safari/Webcore team weren't willing to (or weren't allowed to) accomodate them.
They would probably also be happy to answer questions and explain particular changes.
Weren't.:-)
Look, what Apple is doing with Webcore is (AFAIU again) completely legal. It's just that they're following the strict letter of the law and not at all the spirit of the law. They're not running an opensource project with Webcore, they're building a closed-source project (Safari) and making occasional monolithic code releases of the one major open-source component of that app (Webcore).
Hey, I usually try not to judge people by photos, but she seemed pretty cute in the NYTimes photo. And she's probably smart. Just accept that some people could find her hot, but apparently not you.:)
Thanks for the response, willCode4Beer.com. It's a good response, too. Most of what you say is good, solid, sensible advice:-). I especially agreed with the bit about trying to "make a point" by resigning - I can understand someone wanting to make a point by resigning (hell, that's a large part of what the chap in this case is trying to do), but it should never be a primary (or even a weak secondary ) reason for quitting.
There were a couple of details you tapdanced around a bit, though:).
The best way to quit a job is to quietly disappear.
Well, it's a matter of choice, but I (usually) prefer to not just vanish into nothing (well, unless it was a contract). I like to feel that my ex-co-workers at least noticed I was there.:)
Don't lower yourself to their level, remember you are a PROFESSIONAL, ACT THAT WAY.
The interesting thing about this quote is that sometimes acting professional requires you to refuse to work with people who don't meet the appropriate professional standards (and these people can be of higher or lower or identical seniority). You might well say that it'd be unprofessional to openly criticise a co-worker (and in many cases it would be - and just plain rude as well). But in many cases it could (also?) be significantly more unprofessional to hide the fact that this co-worker is not up to scratch.
And again, I think this is exactly the case as covered by this story. Continuing to work for a company that employs someone as grossly incompetent (and just plain nasty) as that writer leaves you in a situation where it's more damaging to your professional reputation if you do stay.
I mentioned elsewhere in this thread that the term "professional" can be easily abused in this sort of discussion - it sometimes gets massaged into "making any kind of trouble for any reason, ever" being considered "unprofessional". Even when making a small amount of trouble in one place can save an overwhelming amount of trouble further along.:)
Re: the disclosure issue and potential lawsuit-based harassment - well, I can only say I'm glad I don't live in such a fucked-up legal regime if stuff like that actually seriously happens (and if you work in the US, I'm quite willing to believe it can and does) *wry grin*. But anyway, even in the US I'd have to hope that something like that would be fairly unusual and also be fairly easy to successfully defend.
they'll remember that you were the one that made a mess and ran off.
Erm... well, in theory they shouldn't remember that if that wasn't actually the way it happened, should they?:)
I don't equate "burning bridges" to "making a mess and running off", just so you know. I mean it in the sense of just destroying any chance of future polite communication between yourself and EvilBoss (and/or EvilCompany). And yes, sometimes you want it that way.
Aside from that, there's a limit to how much you can afford to worry about what other people think, especially if those people are likely to accept the word of known assholes and liars (ie. baseless slander). *shrug*
If you worry too much about what other people think of you, you risk turning your career into nothing more than a series of popularity contests. And along with that you'll lose the ability to Just Be Yourself(tm).
But anyway, I do actually agree with most of what you say, I'm just looking at it from a slightly different point of view:).
[...] act like a jackass, [...] ignore [...] being civil [...] you [...] act moronic [...] you're childish [...] enjoyment out of causing strife [...] go act like an asshole [...] the retard that you are [...]
Wow. Way to take the ball and run madly off in the wrong direction, op00to:). I think you might have read a few things into my comment that weren't, strictly speaking, there. Nice choice of unnecessary insults, BTW.
I was merely questioning a (seemingly) common viewpoint that is (IMO) overly-weighted towards passively taking abuse with little or no protest... *ahem* sorry, I mean "acting professionally"... when dealing with a bad work environment.
I think it's very easy to find excuses to avoid confrontation with authority figures like a boss (whether pointy-haired or not). It's easy to console yourself that you're acting "professionally" (and what a vague and loaded term that can be) when you don't tell a boss to go fuck him (or her) self, even though he/she has more than earned it.
It's the same old routine, when people don't stand up to a bully (or an asshole (or a lunatic)) in a work environment, but just think "I'll be out of here soon, it won't be my problem anymore," they're really just reinforcing the bully's model of behaviour.
The worry about professionalism and your reputation is just a paper tiger. It's perfectly possibly to burn (or even nuke) bridges while still being professional. And your reputation - well, if a random asshole boss has any genuine influence on your reputation to other people, then your reputation wasn't worth much to start with.
To bring this remotely back on topic, it would have been easier for this LinuxWorld editor chap to keep protesting through "official" channels (ie. in a way that the official people could easily ignore him) and keep doing his job. But instead he decided to take the difficult step of making it a public confrontation, and letting the publisher know that he found their behaviour unacceptable and he wasn't going to put up with it any more (one way or another).
Good on him. He made a choice between what was easy and what was right. And I believe he made the correct choice.
If you back them into a corner, then everybody loses. Your boss/company in order to save face will be forced to maintain its position. You will have burned bridges and look like an extremist in your leaving.
Nothing against you personally, willCode4Beer.com, but it really puzzles me sometimes why people can be so adamant on the "don't burn bridges" line.
It was interesting to read
this article a day or so ago and see various posts going "ohgodohgodohgod whateveryoudoDON'T BURN YOUR BRIDGES!!!" (actually, now I look again, there were a few that didn't)
Maybe it's just me, but I reckon that there's nothing wrong with burning a few bridges every now and then. Hell, nuke the damn bridge, leave the area a smoking radioactive wasteland.
Sometimes you need to say that you've had enough and you just don't give a damn about the bridges anymore.:-)
I wholeheartedly agree, CVs/resumes in HTML are an excellent solution.
The other thing you can do (which I have done) with people that seem to think they must have a MS Word document - is rename the file from *.html to *.doc and change the MIME type (on the email attachment) from text/html to application/msword.
Whatever else you can say about Microsoft Word, even version 97 opens up simple HTML files very nicely. The drones receiving the email never notice the difference - it looks like a MS Word icon in Outlook, when they double-click it opens in MS Word - and I suspect they probably re-save it anyway after munging it and adding to their database.
Anyway, as long as you don't need complex formatting, this works very well. HTML is surprisingly good for short and simple documents (ie. exactly what a CV should be). You just have to let go of your obssession with controlling page breaks.:-)
This is why they are much more well known for buying technology than creating it, starting with their very first product.
I think you'll find that their first product was a BASIC interpreter - and apparently their second and third were Fortran and COBOL compilers, respectively.
The QDOS/MSDOS thing was a bit later.
But aside from my nitpicking the details, I fully agree on the substance of what you were trying to say - they are (or at least were) better known for buying than building. Though they build a hell of a lot more than they buy, and have done so for a while now.
Do you have any reliable information on this, or are you just guessing?
I'd think it very unlikely that any large project (GNU-ish or otherwise) currently based on CVS could convert to GNU Arch - it's just too different on too many levels.
Whereas Subversion is under a perfectly acceptable free software license (even if it's not the GPL and it's not spiritually Free software) and it is a reasonable technical upgrade from CVS, while GNU Arch just isn't.
Purely because I feel the UI is complicated. Of course I've mainly dealt with it on hideously large and complex projects like KDE and Mozilla, so the complexity of the UI may simply be a function of the project's complexity (or, more specifically, a function of Mozilla's complexity, as it was originally designed for Mozilla).
Note that I'm not meaning to slag off Bugzilla at all - it does the job and does it well, as far as I understand. But I wouldn't want to use it for the kind of software I work on (much much smaller and simpler than Moz).
My team is using a combination of Trac and Mantis at the moment - my boss likes Mantis better as a pure bugtracker, but I'm hoping to convert him after Trac 0.9.:)
Good to see another Trac fan helping spread the word. Damn I love that software.
Quite seriously, it would be interesting to see a really major opensource project like KDE switch to Trac - though using Subversion is a necessary first step, so we'll have to wait and see if a few more old-school opensource projects (eg. GCC, OpenOffice, Mozilla, perhaps one of the BSDs) start making the transition from CVS to Subversion.
Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.
The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.
There are lots of other important features of course, but I tend to use it just as a better CVS - which role it fills admirably.
Ye gods. I just had a look through the MySource Matrix site, and... well, going purely by the ludicruous tiny-unreadable-text-image buttons and the spelling and grammar errors all over the place, I'd say that it looks like crap.:)
Their "license" is even sillier. I hope it's not accepted as a valid "open source" license by OSI, that compulsory-copyright-acquisition clause is insidious and nasty.
Plone... yeah, Plone is pretty weird. Powerful, quite flexible, and as long as you don't want to do anything too unusual, fairly straightforward. Of course, as soon as you do want to do something unusual, you'll be lost in a hell of misleading and incomplete documentation.
In the beginning, not _the_ beginning but _A_ beginning, the One True God
did create the "caps lock" key and place it on the Keyboard of Life in the
Garden.
And the Creator saw that it was good. And He smiled down on his creation
and said, "FUCKIN' A!"
Okay, cool, thanks for that information (especially the links). CLOS and/or the MOP is one of the aspects of Common Lisp I haven't played with at all, so I know little or nothing about it. Mind you, I've mainly experimented with SBCL (and a little with CLisp), so I haven't had to deal with those kind of subtle portability problems as yet.
*blink* Okay, I'm intrigued. You were involved in the Common Lisp standardisation process? Or something related?
The result of their lack of good engineering sense and arrogance was the demise of Lisp and the predictable (and predicted) 20 years of dark ages of C/C++ programming. It just boggles the mind that 20 years later, people like you still don't get it.
I guess all the people like me just aren't very bright. Unlike you:).
Look, I know it's tempting to think that you had the answer and everything would be good if they'd just listened to you... but have you ever considered that there might be more than one reason for the so-called "demise" of Lisp?
Perhaps quite a large number of reasons?
I won't even say anything more about Java, since I don't like the language, other than that you seem to know very little about its actual capabilities.
Ah good. Always nice to get in a little snipe, isn't it? Especially over something so trivial and pointless. God, I love it... it makes me feel ALIVE!:-)
It's also a very nice cheap way of avoiding answering the question (said question being "tell me just two 'Lispy' things that Java is implementing"). Which is a pity, as I didn't just ask it as a snide way of suggesting that you were talking out of your arse (though that was a large part). I was actually really interested to hear if there were any new Lispy features scheduled for Java (or indeed any old ones that I hadn't heard of).
Whatever else you or I might say about Java, it has a lot of mindshare - and the horrifying possibility that I might one day use it again might be slightly less horrifying if I knew there were some Lispy features being added to the language. If anyone else reading this can guess what cahiha might have been referring to, please do let me know. Thanks.
Slashdot Mirror
He sure is.
You're a lucky man. Especially for the not-liking-HTML-email part. :)
Source?
For, well, either of those (a) baseless, and (b) totally illogical assertions? :-)
You'd be slightly more convincing if you extended the effort to use google yourself and give us a URL - since you apparently know what you're looking for, you can find it much faster than we can.
Alternatively, what happens is that I search google and find someone's blog entry on BSA-MS-USmarshal-guns, which turns out to be nothing remotely connected to reality. I come back here, respond and say "No, this story is bullshit, see?" You can simply respond and say "No, that's not the story I mean."
Well if you're not completely talking out of your arse, GIVE us a pointer to the specific story you mean. Or if you weren't referring to a single incident, find a story on the indicident that best supports your point (and perhaps pointers to some of the others to back up your insinuation that it's happened more than once).
Because, quite seriously, even in a country with as corrupt a legal system as the USA, I find it difficult to believe that a judge would be willing to disrupt a school's activities for a BSA fishing expedition.
Shit it's hard to handle appropriate levels of contextual quoting in slashdot-HTML - at least for this long a post *wry grin*.
And that's fine - Apple is well within their rights to do that. But doing that makes it a hell of a lot harder to consider Webcore a genuine open source project.
As open as a project like KDE, which has a completely open source control system, a wide array of open and searchable development mailing lists, and an open bugtracking system? No, I though not :-). See below.
You misunderstand my point. I didn't say that Webcore wasn't under an open source license, nor did I suggest that Apple was violating the license in any way.
What I did say was that Apple wasn't running Webcore as an open-source project. A serious OS project should first and foremost have the source developed in an open and freely accessible source control system (though this is not an absolute - many less active OS projects can achieve much the same result with infrequent tarball releases, mainly because updates to the project are infrequent). Less important, but also good, are openly accessible development mailing lists (though again there's some degree of variation here - some projects have a closed "core team" list - but the vast majority keep all lists open). An open and freely accessible bugtracker is also a big plus (though again, there's a fair amount of scope for restricting access to important security-related bugs, as does the Mozilla project with Bugzilla).
Regarding the different priorities between Webcore/KHTML:
Well, it certainly seems to be a big part of the technical problem :).
As far as I'd heard, that was a case of too little, too late and I seem to recall another KDE dev suggesting that Hyatt only did it because he (the KDE dev) dared him to (as they'd been asking for lightweight atomic patches for ages with no response). I hope that's wrong and Hyatt is genuinely trying to help the KHTML project - it certainly looks as though he is, going by his blog.
Re: a comment I made about the Apple devs not being willing to answer question or explain changes:
Actually, no. Dammit. I thought I'd seen a couple of references on the KDE dev blogs regarding the Apple Webcore devs being "unresponsive" to requests for information, but I can't find those references now - I might even have misremembered them. I hereby withdraw that comment.
You're dead right on the opinionated count :). And I'm sorry, I didn't mean to imply I was that well informed :).
My main objection to the "Webcore is a genuine open source project" is covered above - the lack of an openly accessible source control server is a bit of a deal-bre
I'm rather intrigued/puzzled by your comment that "nothing constructive" could be done unless these two disparate projects were using the same source control software.
What on earth makes you think that it'd be any easier to merge changes from one CVS tree to another (different) CVS tree than it would to merge changes from a Perforce tree to a CVS tree (or indeed a Perforce tree to a Subversion tree, as KDE recently converted to Subversion).
Even though this is a kind of a pointless diversion in any case, because Apple aren't providing the KHTML devs (or anyone else) with access to their source control system.
And regarding your PS.... um, well, I don't know any of the KHTML developers personally, but if I were one of them I'd find that comment quite offensive (on several levels).
Well, you see, this is the point - the KHTML devs, from what I've heard, don't really give a crap anymore about what's happening with Webcore. It's a significantly forked project, and practically speaking it'd be more work than it's worth to try to (a) comprehend the Webcore changes, (b) extract those changes, and (c) port the changes back into KHTML. IIRC, one of the KHTML devs said, quite bluntly, that it'd be easier and quicker to write the damn thing themselves than to try to port features from Webcore.
The KHTML people are probably quite happy with the way the code is licensed - people have the freedom to use and modify the code, and they also have the freedom to contribute or NOT contribute back to the parent project. Apple chose to not contribute, which is fine. But (and this is really the core issue) that means they really shouldn't pretend that they are contributing.
That, I believe, is what really shits the KHTML developers.
(As an aside, I have no idea what this "CSS stress test fix" is that you're referring to. Link? If Apple really have made an actual genuine contribution to KHTML, I might have to slightly revise my opinion of them)
The KDE project's CVS (and now Subversion) source control tree is totally open and accessible to anyone (including Apple), has always been that way and will always be that way. Also, the general convention (as I understand it) on large open-source projects like KDE (and especially so on core library components) is that code changes should be made in small, distinct, atomic blocks - with a meaningful commit comment to help comprehend the change (and so the changes can be easily rearranged and merged into, eg. a different branch).
This kind of system makes it relatively easy for the Safari/Webcore team to cherry-pick KHTML changes that they like. Though I have no idea how much they've done this, or even if they've done it at all - for all I know they've taken nothing from KTHML since starting Webcore.
But even so, the existing CVS history helps to understand historical design decisions, and indeed can be helpful in all sorts of subtle ways.
Now, conversely, Apple with Webcore. The KHTML team have no access to the Webcore source control system (it's not being run as a truly open open-source project, even if it is under the LGPL). The KHTML team have (AFAIU) only limited access to the Webcore bugtracking system, with some bugs not visible at all. From the story: "[KHTML] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code."
Whatever Apple uses for a source control system is utterly and totally irrelevant. What is relevant is that their source control system is not publically accessible. You can't see changes as they're made, you can't track the development trunk. All you can do is take the occasional slabs of code that they release - and the whole point is that that makes it difficult to port interesting code changes into the KHTML codebase.
Added to which, the Safari/Webcore developers have entirely different (ie. commercial) priorities to the KHTML project. The KHTML team are prepared to take more time and do it right. The Webcore team are not - so they're more likely to use kludgy, lower-quality hacks that are simply unacceptable to the KHTML team.
And the Apple developers have done another thing which makes things even more difficult for the KHTML devs to use their changes - they're using significant closed-source functionality from Mac OSX system libraries... thus building in a dependency to a closed library. Which makes it even harder to work out what's happening when Webcore makes a call out to an external library to accomplish some vital task.
Wow, you really haven't read any of the background on this at all, have you? The KDE/KHTML team did ask (many, many times), and the Safari/Webcore team weren't willing to (or weren't allowed to) accomodate them.
Weren't. :-)
Look, what Apple is doing with Webcore is (AFAIU again) completely legal. It's just that they're following the strict letter of the law and not at all the spirit of the law. They're not running an opensource project with Webcore, they're building a closed-source project (Safari) and making occasional monolithic code releases of the one major open-source component of that app (Webcore).
Hey, I usually try not to judge people by photos, but she seemed pretty cute in the NYTimes photo. And she's probably smart. Just accept that some people could find her hot, but apparently not you. :)
Thanks for the response, willCode4Beer.com. It's a good response, too. Most of what you say is good, solid, sensible advice :-). I especially agreed with the bit about trying to "make a point" by resigning - I can understand someone wanting to make a point by resigning (hell, that's a large part of what the chap in this case is trying to do), but it should never be a primary (or even a weak secondary ) reason for quitting.
There were a couple of details you tapdanced around a bit, though :).
Well, it's a matter of choice, but I (usually) prefer to not just vanish into nothing (well, unless it was a contract). I like to feel that my ex-co-workers at least noticed I was there. :)
The interesting thing about this quote is that sometimes acting professional requires you to refuse to work with people who don't meet the appropriate professional standards (and these people can be of higher or lower or identical seniority). You might well say that it'd be unprofessional to openly criticise a co-worker (and in many cases it would be - and just plain rude as well). But in many cases it could (also?) be significantly more unprofessional to hide the fact that this co-worker is not up to scratch.
And again, I think this is exactly the case as covered by this story. Continuing to work for a company that employs someone as grossly incompetent (and just plain nasty) as that writer leaves you in a situation where it's more damaging to your professional reputation if you do stay.
I mentioned elsewhere in this thread that the term "professional" can be easily abused in this sort of discussion - it sometimes gets massaged into "making any kind of trouble for any reason, ever" being considered "unprofessional". Even when making a small amount of trouble in one place can save an overwhelming amount of trouble further along. :)
Re: the disclosure issue and potential lawsuit-based harassment - well, I can only say I'm glad I don't live in such a fucked-up legal regime if stuff like that actually seriously happens (and if you work in the US, I'm quite willing to believe it can and does) *wry grin*. But anyway, even in the US I'd have to hope that something like that would be fairly unusual and also be fairly easy to successfully defend.
Erm... well, in theory they shouldn't remember that if that wasn't actually the way it happened, should they? :)
I don't equate "burning bridges" to "making a mess and running off", just so you know. I mean it in the sense of just destroying any chance of future polite communication between yourself and EvilBoss (and/or EvilCompany). And yes, sometimes you want it that way.
Aside from that, there's a limit to how much you can afford to worry about what other people think, especially if those people are likely to accept the word of known assholes and liars (ie. baseless slander). *shrug* If you worry too much about what other people think of you, you risk turning your career into nothing more than a series of popularity contests. And along with that you'll lose the ability to Just Be Yourself(tm).
But anyway, I do actually agree with most of what you say, I'm just looking at it from a slightly different point of view :).
Wow. Way to take the ball and run madly off in the wrong direction, op00to :). I think you might have read a few things into my comment that weren't, strictly speaking, there. Nice choice of unnecessary insults, BTW.
I was merely questioning a (seemingly) common viewpoint that is (IMO) overly-weighted towards passively taking abuse with little or no protest... *ahem* sorry, I mean "acting professionally"... when dealing with a bad work environment.
I think it's very easy to find excuses to avoid confrontation with authority figures like a boss (whether pointy-haired or not). It's easy to console yourself that you're acting "professionally" (and what a vague and loaded term that can be) when you don't tell a boss to go fuck him (or her) self, even though he/she has more than earned it.
It's the same old routine, when people don't stand up to a bully (or an asshole (or a lunatic)) in a work environment, but just think "I'll be out of here soon, it won't be my problem anymore," they're really just reinforcing the bully's model of behaviour.
The worry about professionalism and your reputation is just a paper tiger. It's perfectly possibly to burn (or even nuke) bridges while still being professional. And your reputation - well, if a random asshole boss has any genuine influence on your reputation to other people, then your reputation wasn't worth much to start with.
To bring this remotely back on topic, it would have been easier for this LinuxWorld editor chap to keep protesting through "official" channels (ie. in a way that the official people could easily ignore him) and keep doing his job. But instead he decided to take the difficult step of making it a public confrontation, and letting the publisher know that he found their behaviour unacceptable and he wasn't going to put up with it any more (one way or another).
Good on him. He made a choice between what was easy and what was right. And I believe he made the correct choice.
Nothing against you personally, willCode4Beer.com, but it really puzzles me sometimes why people can be so adamant on the "don't burn bridges" line. It was interesting to read this article a day or so ago and see various posts going "ohgodohgodohgod whateveryoudoDON'T BURN YOUR BRIDGES!!!" (actually, now I look again, there were a few that didn't)
Maybe it's just me, but I reckon that there's nothing wrong with burning a few bridges every now and then. Hell, nuke the damn bridge, leave the area a smoking radioactive wasteland.
Sometimes you need to say that you've had enough and you just don't give a damn about the bridges anymore. :-)
I wholeheartedly agree, CVs/resumes in HTML are an excellent solution.
The other thing you can do (which I have done) with people that seem to think they must have a MS Word document - is rename the file from *.html to *.doc and change the MIME type (on the email attachment) from text/html to application/msword.
Whatever else you can say about Microsoft Word, even version 97 opens up simple HTML files very nicely. The drones receiving the email never notice the difference - it looks like a MS Word icon in Outlook, when they double-click it opens in MS Word - and I suspect they probably re-save it anyway after munging it and adding to their database.
Anyway, as long as you don't need complex formatting, this works very well. HTML is surprisingly good for short and simple documents (ie. exactly what a CV should be). You just have to let go of your obssession with controlling page breaks. :-)
I think you'll find that their first product was a BASIC interpreter - and apparently their second and third were Fortran and COBOL compilers, respectively. The QDOS/MSDOS thing was a bit later.
But aside from my nitpicking the details, I fully agree on the substance of what you were trying to say - they are (or at least were) better known for buying than building. Though they build a hell of a lot more than they buy, and have done so for a while now.
Do you have any reliable information on this, or are you just guessing?
I'd think it very unlikely that any large project (GNU-ish or otherwise) currently based on CVS could convert to GNU Arch - it's just too different on too many levels. Whereas Subversion is under a perfectly acceptable free software license (even if it's not the GPL and it's not spiritually Free software) and it is a reasonable technical upgrade from CVS, while GNU Arch just isn't.
Purely because I feel the UI is complicated. Of course I've mainly dealt with it on hideously large and complex projects like KDE and Mozilla, so the complexity of the UI may simply be a function of the project's complexity (or, more specifically, a function of Mozilla's complexity, as it was originally designed for Mozilla).
Note that I'm not meaning to slag off Bugzilla at all - it does the job and does it well, as far as I understand. But I wouldn't want to use it for the kind of software I work on (much much smaller and simpler than Moz).
My team is using a combination of Trac and Mantis at the moment - my boss likes Mantis better as a pure bugtracker, but I'm hoping to convert him after Trac 0.9. :)
I understand that Trac support for multiple projects (along with a few other features) is due soon - I believe as part of the upcoming 0.9 release.
Thanks for the pointers re: Scarab and GForge though, I'll have a look at them. Always nice to keep up-to-date with the alternatives. :)
Eh, it happens, don't worry about it :).
Good to see another Trac fan helping spread the word. Damn I love that software.
Quite seriously, it would be interesting to see a really major opensource project like KDE switch to Trac - though using Subversion is a necessary first step, so we'll have to wait and see if a few more old-school opensource projects (eg. GCC, OpenOffice, Mozilla, perhaps one of the BSDs) start making the transition from CVS to Subversion.
Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.
The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.
There are lots of other important features of course, but I tend to use it just as a better CVS - which role it fills admirably.
Great!
Now when are they going to be switching from Bugzilla to Trac?
(insert ha-ha-only-serious-cos-Bugzilla-scares-me smiley here)
Ye gods. I just had a look through the MySource Matrix site, and... well, going purely by the ludicruous tiny-unreadable-text-image buttons and the spelling and grammar errors all over the place, I'd say that it looks like crap. :)
Their "license" is even sillier. I hope it's not accepted as a valid "open source" license by OSI, that compulsory-copyright-acquisition clause is insidious and nasty.
Plone... yeah, Plone is pretty weird. Powerful, quite flexible, and as long as you don't want to do anything too unusual, fairly straightforward. Of course, as soon as you do want to do something unusual, you'll be lost in a hell of misleading and incomplete documentation.
The story of the garden of capslock Eden
Okay, cool, thanks for that information (especially the links). CLOS and/or the MOP is one of the aspects of Common Lisp I haven't played with at all, so I know little or nothing about it. Mind you, I've mainly experimented with SBCL (and a little with CLisp), so I haven't had to deal with those kind of subtle portability problems as yet.
*blink* Okay, I'm intrigued. You were involved in the Common Lisp standardisation process? Or something related?
I guess all the people like me just aren't very bright. Unlike you :).
Look, I know it's tempting to think that you had the answer and everything would be good if they'd just listened to you... but have you ever considered that there might be more than one reason for the so-called "demise" of Lisp?
Perhaps quite a large number of reasons?
Ah good. Always nice to get in a little snipe, isn't it? Especially over something so trivial and pointless. God, I love it... it makes me feel ALIVE! :-)
It's also a very nice cheap way of avoiding answering the question (said question being "tell me just two 'Lispy' things that Java is implementing"). Which is a pity, as I didn't just ask it as a snide way of suggesting that you were talking out of your arse (though that was a large part). I was actually really interested to hear if there were any new Lispy features scheduled for Java (or indeed any old ones that I hadn't heard of).
Whatever else you or I might say about Java, it has a lot of mindshare - and the horrifying possibility that I might one day use it again might be slightly less horrifying if I knew there were some Lispy features being added to the language. If anyone else reading this can guess what cahiha might have been referring to, please do let me know. Thanks.