Just yesterday evening, I was browsing PC games at the local store, having reinstalled a Windows partition recently, and spotted the box version of Portal. Awesome, I told myself, been wanting to play that one ever since I heard of it, let's purchase this shit. (Mind you, everything about the plot and even the ending are utterly spoiled by now, but who cares, the gameplay seems terrific.)
But for safety, I checked out the small print at the back of the box.
Which said something along the lines of, the game you are shelling out money for will just plain not run outright, you'll have to allow it to go online and then maybe our servers will allow it to run if you accept an EULA that you'll know nothing about until then.
End result: no go, sorry. If I give money for a product, I want it to run when I feel like running it. One less sale for you, dude. (Not that you give a damn about one sale, I'm sure.)
Thank you for taking the time to post your own opinion!
Perhaps you will forgive me to point out that your assumption is mistaken: the view I posted regarding Zend Framework comes from internal company research. You are indeed correct in that I didn't choose to use ZF personally, but are mistaken in your assumption that my views are based on simple hearsay rather than actual first-hand investigation.
However, I find your comment about the blogosphere interesting, because it raises two questions:
Firstly, am I to understand that ZF doesn't meet the expectations for a 'true' framework, whatever that means to each individual user, in the blogosphere at large either? I'll admit to you that I do not follow the PHP blogosphere and I thus have no opinion on that either way.
Secondly, while I of course can't rule out the possibility we failed to give ZF due credit in out research, if a significant number of people indeed came to the same conclusion we did, wouldn't you say it possible that this conclusion has some grain of truth to it?
I am not comfortable pushing this matter a lot further because obviously you care a lot about your product, and it seems like the opinion that users such as ourselves came to form about it is profoundly disagreeable to you. However, perhaps you will forgive me for suggesting you take a step back and consider the possibility there might exist some leeway for you to improve your product, so that it better matches the implicit expectations that your users have for what constitutes a framework? I fully acknowledge the possibility it's us who came to the wrong conclusion; whether you'll choose to consider the other possibility, however, is your own decision.
I understand the Zend Framework is not so much a framework as a tight collection of helper tools. If you want a framework, as in, framework, you'll probably want to look into CakePHP. Symfony is more powerful, but also kind of more complicated. (And declaring my models in XML makes my skin crawl -- but it's just me.)
Secondly:
> Would it be worth my time to learn Python and then do the project in Django?
Short answer: If you know PHP really well and it works for you, it'll be less work (and less risk) to just keep using PHP.
Long answer: If you're a fast learner, and intend to keep using Django afterwards so the overhead of learning it is worth it, then I'd say, absolutely. If I were in your shoes, I believe I would probably create a small functional site in Django in my spare time -- it doesn't take very long at all to get a blog with comments up and running, for instance -- and see how it flies with me. I understand learning Python and Django hand in hand works very fine, although I can't personally comment on that, having been into Python for many years.
If you go the Django road, you'll probably find these resources handy:
The Django community aggregator is at http://www.djangoproject.com/community/ and has many good posts with great insight on how to get the best out of your new Django toy.
The Django Snippets site at http://www.djangosnippets.org/ is a great catalog of small, useful bits of code. I read it in my RSS aggregator, personally.
And of course, there's the #django IRC channel, and the various mailing-lists.
Enjoy exploring Django! I've been following it for a few months already and still don't hate it, and for an old bitter bastard like me, that's the biggest praise.
The real disturbing thing is that you are asking this question at all. Here's why.
What is nowadays wrapped under the common label of 'intellectual property' (copyrights, patents, trademarks) was never, EVER, intended as any manner of property.
The ONLY purpose of patents and copyrights (trademarks being a different thing altogether) is to maximize the availability of intellectual production in the public domain.
Let me repeat that: their only purpose is to help along the enrichment of the public domain.
The temporary exploitation monopoly rights that both copyrights and patents allow are only means to that end; they only exist to make investment in creation and invention economically worthwhile. They were never, ever, meant as the end itself, regardless of what mind-boggingly rich executives would have you believe.
Which makes the very term of intellectual property a misnommer of outright Sapir-Whorf scale; let us please stop using it and denounce its use? Thanks. Intellectual creations don't belong to anyone; we just grant their creators a temporary exclusivity on the rights to make money of them. And that's all there ever was to it.
(Note: IANAL, but the above comes straight from the law courses that were mandatory in my tech studies; details may vary from country to country. Mandatory law courses didn't make me happy at the time, mind you, but man, have they come in handy since then.)
My two cents: I've only just started in my advance copy of 'Foundations of Qt Development' by Johan Thelin but thus far it looks fairly good. I should probably post a review when I've read it cover to cover, actually.
> Rails has been translated several times to other languages, like Python (Django...)
Absolutely not. Django preexisted the Rails buzz by years (it was an internal application at LJworld initially), and one of the reasons it's so good is that, unlike many, it is precisely not trying to mimic Rails.
That doesn't invalidate your point, though. I just thought I'd point it out, because, you know, to reach the next milestone, you first need to stop targetting the current one, and as you point out, not many are doing that right now.
I wonder if anybody else still remembers what Stéphane Picq was able to do on the Dune soundtrack with a mere Ad Lib sound card? Damn, I loved what that guy made so much. I still own the Lost Eden soundtrack CD -- back in the day, making CDs of video game musics was unheard of. Gosh, I feel old now.:)
> Perhaps you can explain to me why exactly you feel that doing the same is not plausible > for Linux? Certainly it's how a commercial/non-free packages I've used in the past have > been distributed (wordperfect, java, informix).
There are, I think, two questions hidden in your question:
Why do I feel so? Because I write software for all three major platforms, and shipping software that just works out of the box on Linux is, simply, a pain. Now if you know something I don't about packaging software on Linux, which I am entirely willing to believe, mind, now would be a great time to share.
Now, why do I reason so, which is very much not the same thing? Mostly because of the issues brought up in the Autopackage page which I linked to and which I doubt you read, and because I know the culture attached to Linux -- and as I said in my initial post, the issue is at heart one of culture, not a technical one. If we set our hearts on making it happen, then it would probably not be too terribly complicated, technically speaking. And yet what do we see happening instead? People posting on Slashdot about how it needn't happen, citing examples that fall exactly within the realm of pain-in-the-ass that was described in the parent post.
Because it's not about whether it's feasible, dear. Of course it's feasible. But it is still complicated, costly, it generally requires hacks and shipping different versions for different flavours of Linux or, in the Java VM's case, not linking against ANY Linux library beside libc.
So, yes, a few companies with a vested interest in Linux go out of their way to support Linux despite the hurdles. And that's very, very much not the same thing as making it straightforward enough, that neutral third parties without a vested interest in Linux will find it cost-effective to support our platform.
And the only, the only thing that we can do about this issue is try to bring awareness of it among our own ranks.
Well, it's something I've been thinking a lot over the last years, and I'd like to share my thinking with you lot:
At this point, I don't think we're going to have a major breakthrough until Linux becomes third-party friendly.
Let me explain.
At the moment, the whole experience of using a Linux distribution is balanced between two parties: the user, and the developers of the distro. Linux distributions in general have come a LONG way in minding the user's convenience, but I am still not sure this will suffice.
Because the success of other platforms (well, Windows, alright) doesn't boil down to user friendliness, I think that much is clear by now. No, what made its success is that it fosters a rich environment of third parties -- entities that are neither the OS maker nor the user, yet benefits both.
Something that is still a long way from penetrating the Linux culture, I think.
At this point, let's imagine you're a third party (and as such, not particularly involved in the Linux world as such -- to you it's just a platform among others) and you wish to ship your software for Linux. What are your options? Well, and that's assuming you're even going to bother trying to figure out the whole mess, you can: try to ship various packages (.rpm and.deb, really) in the hope of covering a sufficient user base, while hoping it won't completely break next time some distro upgrades to libwhatever.so.52; or you can try to get your software into the package repositories of all the major distributions (and thus become entirely dependant on the goodwill of each distro for access to your software); or you can try to package the software your own way and hope for the best (that's what Loki did for their games, for instance), which is still vastly suboptimal because it's a lot of additional work for you and you still have no guarantee it'll work well, due to countless issues, the least of which not being that ELF has real, real issues where it comes to binary compatibility. Oh, and yeah, you can also just ship the sources in a tarball, hereby reducing your user base to the demographic of Linux geeks.
Compare with Windows: just put the binaries in a ZIP file or an installer. Done.
And let us not mention the issue of drivers. At this point, shipping a driver for Linux, when you're a neutral hardware maker third party, involves either sending the kernel maintainers your code and hope they'll consent to include it in the main kernel tree at some unknown point in the future, or ship some manner of hack that will try to compile your driver against the installed kernel, which will simply not work if the compiler, or even the right kernel headers, aren't already installed. (To be fair, the initiative that was recently spoken of on Slashdot, about some company developing Linux drivers for third parties for free, is interesting and might improve the situation lots.)
In short: when you're a third party, supporting Linux is generally not worth the pain.
This is a very bad situation for us, because we need hardware makers to support our platform, so there isn't an ongoing gap of weeks or months between the release of bleeding edge hardware and its support on Linux, and there is just plain not enough of us to reproduce the functionality of all the software third parties are making for other platforms
Admittedly, projects like Klik and Autopackage are a step in the right direction, but isn't it too little and perhaps even too late? I don't know.
Because the main, the core issue here is not technical.
The core issue is that when you discuss something like Autopackage, the response typically amounts to "Why don't you use.debs | use.rpms | fork your own distro?"
And this, my friends, is why I've lost hopes of seeing the Linux desktop go mainstream.
> And let me note that in France, ID is nationally issued and you're required to carry it > everywhere.
Uh, no. There is such a thing as a national ID card, but having one is optional since 1955 (and free since 1998). As far as I can tell, you are only to carry a driving license to your name when at the wheel, and you have to be able to prove you're not an illegal immigrant -- hence your working visa.
Mind, I could write whole BOOKS on the ways in which France sucks, so don't take the above wrong; I just thought I'd point out some factually wrong element in your otherwise interesting comment.
1) De-facto standards, where a given arbitrary product is the reference, and codified standards, as described for open implementation, are VASTLY different things. Can you tell why? (Here's a hint: the answer contains the words 'lock-in'. I'll let you ponder that while ruing the lack of Firefox and XUL user base.)
2) However, reference implementations are a good thing, because they, as you rightly point out, help developers. Not providing a reference implementation of CSS is possibly the biggest mistake the W3C made.
3) In a perfect world, you'd be using just whatever the hell you want and it would make no matter. Gecko lock-in is not much better than IE lock-in. (Case in point: browse the commit logs of other browsers and count how many entries there are that go, "Emulate Firefox bug such-and-such so as to display somesite.com correctly". Seriously.)
And lastly,
4) I am slightly annoyed that you seem to assume I don't know about Web development. Because, meanwhile, in the real world, our issue tracking system is littered with tickets that read something like:
"Dear Mr. Important-customer-at-huge-company, The issue you report looks like a bug in Internet Explorer. We'll allocate developer ressources to implement a work around for the next revision of the product. Kind regards, etc..."
This costs money. This costs resources that could be allocated to building better mousetraps, to make awesome shit, to create stuff to be proud of and to drive things ahead. Instead... Working in this field today is trying to build castles on swamps, and it's a daily struggle to not cave in and just sell shaky wooden shacks (painted cheap gold as per marketing's instructions) like the rest of 'em.
And this is not something I can do anything about.
However, you can.
Will you, in all consciousness, make the choice to be part of the problem? That choice is yours and yours only.
Actually, the KDE guys (in particular, the ever awesome Zack Rusin) are working with the WebKit people in order to make WebKit work on the same rendering canvas that KDE uses (namely Qt's QPainterDevice). So Konqueror 4 will most likely use WebKit itself, rather than KHTML, on all three platforms, Linux, Windows and Mac.
The reason why this is such great news is that this could possibly make WebKit, one of the most standard compliant engines out there, the number one option after IE (alongside with Gecko), which will hopefully prompt Web developers to, at last, respect the standards as the basics for any Web development.
... Just so long as WebKit doesn't end up deviating from the standards for whichever reason, anyway. Y'know. (Yeah, I've been in this industry too long to remain optimistic, I know.)
I've long thought that distros generally prefer GNOME (probably for license and looks-better-out-of-the-box reasons) but users have different criteria about desktop environment choices (looks better after tweaking, does everything you want, fast, and otherwise remains very much out of your way, etc). It is interesting that distros and users should have wants driving them to opposite choices, though, and probably goes to show that Linux has already spread far, far beyond the demographic of geeks that take part in its development.
1) Procmail can actually detect mail sent from daemons. 2) It matters not that you give out many different addresses to different entities so long as you keep only a small list of addresses to SEND mail.
Based on this, you can tell procmail to filter anything that comes form a daemon (bounces, in particular) and is not addressed to one of your sender addresses.
This will put bounced spams into the ~/Mail/spambounce/ directory. Review this directory now and then in case legitimate daemon-sent email ends up there.
Once done, investigate SPF, and have an SPF entry added to your domain. This makes your domain much less interesting to use for return addresses, and spammers are likelier to stop using it when they take notice (which might take a few months, be patient).
Worked for me anyway. (Worked damn fine, actually.)
Holy shit. The cheek of it. "Until then, expect some elaborately spun responses from Sony's competitors." Really.
Reality check: Sony sold 165,000 PS3 and the rest are already sitting on shelves. Nintendo shipped how many times that many Wii? and is still sold out. How the HELL is that good news for Sony? Someone please explain me, I really don't understand...
> There are quite a few people used to the old world where a string was interchangeable with a > vector of 8 bit bytes
No. No, no, no. NO. Please, no. Seriously. This is bad. A LOT of damage happens because people can't be bothered to spend the 10 minutes it takes to learn the basics of Unicode. It's easy. I don't always think very highly of what Joel Spolsky writes, but his introduction to Unicode is an ABSOLUTE must-read.
Seriously. Strings are NOT interchangeable with byte arrays. EVER. Without an encoding information, a byte array can represent a wild number of different strings. Without an encoding information, you can't even tell where the string that the byte array represents ends! This is one of my pet peeves, really -- pretending that byte arrays and strings are equivalent is on the same level of professionalism as pretending that the data won't ever be larger than your buffer. Ignoring issues that bother you don't make them go away.
Short answer: various things, compilation to bytecode before execution (I thought it was the case in the current interpreter, but might have been mistaken), etc.
Slightly less short answer: if I'm not mistaken, YARV includes a JIT compiler, similar to what Psyco does in the Python world. Psyco has been known to accelerate code execution up to 100x times, so I'd expect YARV to be even faster than this benchmark shows when it's stabilized.
Okay, I generally try not to make snarky comments, but, with my apologies, please allow me to indulge briefly.:)
> With PHP, it's simple -- your test machine is probably set up already, and your deployment > webserver almost certainly is.
<snark>Are you FUCKING kidding me?</snark>
(Golly, I already feel better.):)
Now please allow me to expand.
Deploying for PHP is an insane pain in the ass. PHP breaks compatibility at every turn on the wind (fun fact: the product I'm paid to deploy for a large company right now doesn't run on the very latest PHP... and the previous version has since had security holes discovered, joy). PHP's behavior depends strongly on the host configuration, which may vary wildly and to which you may not even have access. Availability of certain features is conditioned by how PHP was compiled, which you might have no control on. PHP is not thread-safe and may wreck your data on certain Apache configurations. And so on, and so on.
Since Python was brought up in this thread, let's compare. Python has an API called WSGI that plugs into pages or frameworks on the client side, and Web servers on the server side, and any WSGI-compliant server method and framework will do. All the Python-based frameworks, Django, TurboGears, Web.py, Pylons, etc, support WSGI. Apache with mod_python or CGI or FastCGI or FCGID support WSGI. Lighttpd has a WSGI module, I believe. Whatever is available for you will do for a Python framework so long as there's a WSGI interface for it, and there's a WSGI interface for pretty much everything these days (although some googling might be in order in some cases). Recently, I deployed one of the largest Python frameworks under a very restricted platform that only allowed CGI: it worked just fine. In fact, I imagine it shouldn't be exceedingly hard to code a small PHP handler that would delegate calls to WSGI, which would allow you to deploy a Python framework wherever PHP is installed. Now that would be fun.:)
Also, Python has a standard library that can be counted on everywhere it's available, and I had never before understood how much of a boon that can be, honestly. It's also thread-safe (although it does pay a price for this safety -- when you know that price and when it matters and when it doesn't, be proud of yourself, because you'll then know one of that tool's flaws, and knowing that is the beginning of mastery).
Mind, I'm not telling you to drop everything and start courting snakes right away, because that's not my fucking call -- it's yours. Do NOT switch tools if you don't know, personally, WHY you should; everybody will be happier in the end that way (but I do encourage you to learn new tools when you can and what they're good for and why they're good; it's healthy for the mind). But I find your comment interesting, because it implicitly connected an unknown (deploying under Python) with a difficulty comparatively to your current known way, regardless of the inherent flaws of that way. Interesting, how the mind works, isn't it?:)
This being said, dropping an 'hello world' in some directory and having it work right away is something PHP still does better; in fact, it's simply great at it. It's when you start using non-trivial functionalities that things go downhill.
Anyway. As a conclusion: do me a favor, forget Python for at least a day, and go learn Ruby instead at first. Why? Because I would like you to learn why you're using the tools you are, and listening to some random dude on the Net about some random language is quite probably not how you'll achieve that.
Thanks for reading! (And sorry, I tend to be a bit verbose, I know.)
Alright, I'm a little busy right now so I won't go into as much detail as I'd like, but here are the basics as far as I understand them.
1) Design patterns still apply. More than ever, actually. If you've not read the GoF, it features a pretty advanced example centered on the design of a rich text editor. You will probably want to dive deeply into the workings of the Model-View-Controller pattern and the related design constructs. The MVC pattern is not the be all and end all of GUI design, and there are many cases where the articulation between View and Controller
2) You may not now it yet, but you want loose coupling. Loose coupling means that, essentially, when a widget's state change, it will report on that change, and some interested party will be notified about it, and neither will have to know anything about the other. Many toolkit nowadays come with good signal and slot mechanisms to implement loose coupling. Understand them, and use them. If you find the sender of a signal and the receiving slot need to know about each other, you may want to go back to the drawing board as suggested in point #1 above; it is usually not necessary.
Conceiving GUIs is not all about the underlying software architecture, though; a good chunk of the work of making great interfaces is in the designing of the GUIs themselves (which is why you want loose coupling -- you WILL have to be flexible against changes as you experiment). I will let others fill you in about that. Quickly: read usability guidelines and get a feel for why they suggest what they suggest. Align your widgets! NetBeans is good for this, IIRC. Use GUI designer tools, experiment more.
That's all I can think of off the top of my head, but there's already a lot for you to chew in there.:) Hopefully other people will have more details to give you.
All in all, it boils down to the usual rules of engineering: the second rule is to know what works, and the first rule is to know why it works.
Just so people who may come across this know, if you're going to do some HTML or XHTML parsing in Python, you'd be insane not to use BeautifulSoup or a similar tool.
Example to find all links in a document:
from BeautifulSoup import BeautifulSoup for tag in BeautifulSoup(html_document).findAll("a"):
print tag["href"]
Yes, it's that simple. For an URL opener that also handles proxies, cookies, HTTP auth, SSL and so on, look into the urllib2 module that ships natively with Python.
Watch out, regarding code comments. They are important, even given the best written code in the world. Why? Well, a well-written code -- which is also a mandatory thing, to me -- will make it very clear WHAT is being done. A comment's purpose is different: comments should tell you WHY it's being done this way.
Example of a typical bad comment:
buf[BUF_SIZE-1] = 0;/* set last byte to 0 */
And a better comment:
buf[BUF_SIZE-1] = 0;/* fill_my_buffer() sometimes fails to 0-end the buffer, making it incompatible with str* functions, so we add it here.*/
Depending on how conscientious you are, you might even want to explain why it's BUF_SIZE-1 and not BUF_SIZE. Yes, of course, YOU know. Right now. The next person peeking at the code -- which might be yourself, in three years and in a hurry -- might not, though.
I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulnerable to the bugs of the previous release until you're done; or you don't intercept it, and have your production sites break in various ways.
(I am not going to go into why the very concept of a nl2br() function is fundamentally broken; that's matter for another time.)
It may be that you like PHP for your own reasons, and that's all good and fair, but please, please don't try to brush this kind of serious issues under the carpet. Doing so is doing a disservice to your language. It's only by expecting its developpers to do things right that you'll incite them to move away from the bad practice that are giving a language you may be fond of such a bad reputation.
Slashdot Mirror
Just yesterday evening, I was browsing PC games at the local store, having reinstalled a Windows partition recently, and spotted the box version of Portal. Awesome, I told myself, been wanting to play that one ever since I heard of it, let's purchase this shit. (Mind you, everything about the plot and even the ending are utterly spoiled by now, but who cares, the gameplay seems terrific.)
But for safety, I checked out the small print at the back of the box.
Which said something along the lines of, the game you are shelling out money for will just plain not run outright, you'll have to allow it to go online and then maybe our servers will allow it to run if you accept an EULA that you'll know nothing about until then.
End result: no go, sorry. If I give money for a product, I want it to run when I feel like running it. One less sale for you, dude. (Not that you give a damn about one sale, I'm sure.)
Greetings,
Thank you for taking the time to post your own opinion!
Perhaps you will forgive me to point out that your assumption is mistaken: the view I posted regarding Zend Framework comes from internal company research. You are indeed correct in that I didn't choose to use ZF personally, but are mistaken in your assumption that my views are based on simple hearsay rather than actual first-hand investigation.
However, I find your comment about the blogosphere interesting, because it raises two questions:
Firstly, am I to understand that ZF doesn't meet the expectations for a 'true' framework, whatever that means to each individual user, in the blogosphere at large either? I'll admit to you that I do not follow the PHP blogosphere and I thus have no opinion on that either way.
Secondly, while I of course can't rule out the possibility we failed to give ZF due credit in out research, if a significant number of people indeed came to the same conclusion we did, wouldn't you say it possible that this conclusion has some grain of truth to it?
I am not comfortable pushing this matter a lot further because obviously you care a lot about your product, and it seems like the opinion that users such as ourselves came to form about it is profoundly disagreeable to you. However, perhaps you will forgive me for suggesting you take a step back and consider the possibility there might exist some leeway for you to improve your product, so that it better matches the implicit expectations that your users have for what constitutes a framework? I fully acknowledge the possibility it's us who came to the wrong conclusion; whether you'll choose to consider the other possibility, however, is your own decision.
Thank you for reading.
Firstly:
> I'm planning on using the Zend Framework
I understand the Zend Framework is not so much a framework as a tight collection of helper tools. If you want a framework, as in, framework, you'll probably want to look into CakePHP. Symfony is more powerful, but also kind of more complicated. (And declaring my models in XML makes my skin crawl -- but it's just me.)
Secondly:
> Would it be worth my time to learn Python and then do the project in Django?
Short answer: If you know PHP really well and it works for you, it'll be less work (and less risk) to just keep using PHP.
Long answer: If you're a fast learner, and intend to keep using Django afterwards so the overhead of learning it is worth it, then I'd say, absolutely. If I were in your shoes, I believe I would probably create a small functional site in Django in my spare time -- it doesn't take very long at all to get a blog with comments up and running, for instance -- and see how it flies with me. I understand learning Python and Django hand in hand works very fine, although I can't personally comment on that, having been into Python for many years.
If you go the Django road, you'll probably find these resources handy:
The Django community aggregator is at http://www.djangoproject.com/community/ and has many good posts with great insight on how to get the best out of your new Django toy.
The Django Snippets site at http://www.djangosnippets.org/ is a great catalog of small, useful bits of code. I read it in my RSS aggregator, personally.
And of course, there's the #django IRC channel, and the various mailing-lists.
Enjoy exploring Django! I've been following it for a few months already and still don't hate it, and for an old bitter bastard like me, that's the biggest praise.
Kopete updates its version file automatically, so no need to edit anything. Kopete will do it for you.
The real disturbing thing is that you are asking this question at all. Here's why.
What is nowadays wrapped under the common label of 'intellectual property' (copyrights, patents, trademarks) was never, EVER, intended as any manner of property.
The ONLY purpose of patents and copyrights (trademarks being a different thing altogether) is to maximize the availability of intellectual production in the public domain.
Let me repeat that: their only purpose is to help along the enrichment of the public domain.
The temporary exploitation monopoly rights that both copyrights and patents allow are only means to that end; they only exist to make investment in creation and invention economically worthwhile. They were never, ever, meant as the end itself, regardless of what mind-boggingly rich executives would have you believe.
Which makes the very term of intellectual property a misnommer of outright Sapir-Whorf scale; let us please stop using it and denounce its use? Thanks. Intellectual creations don't belong to anyone; we just grant their creators a temporary exclusivity on the rights to make money of them. And that's all there ever was to it.
(Note: IANAL, but the above comes straight from the law courses that were mandatory in my tech studies; details may vary from country to country. Mandatory law courses didn't make me happy at the time, mind you, but man, have they come in handy since then.)
My two cents: I've only just started in my advance copy of 'Foundations of Qt Development' by Johan Thelin but thus far it looks fairly good. I should probably post a review when I've read it cover to cover, actually.
> Rails has been translated several times to other languages, like Python (Django...)
Absolutely not. Django preexisted the Rails buzz by years (it was an internal application at LJworld initially), and one of the reasons it's so good is that, unlike many, it is precisely not trying to mimic Rails.
That doesn't invalidate your point, though. I just thought I'd point it out, because, you know, to reach the next milestone, you first need to stop targetting the current one, and as you point out, not many are doing that right now.
I wonder if anybody else still remembers what Stéphane Picq was able to do on the Dune soundtrack with a mere Ad Lib sound card? Damn, I loved what that guy made so much. I still own the Lost Eden soundtrack CD -- back in the day, making CDs of video game musics was unheard of. Gosh, I feel old now. :)
> Perhaps you can explain to me why exactly you feel that doing the same is not plausible
> for Linux? Certainly it's how a commercial/non-free packages I've used in the past have
> been distributed (wordperfect, java, informix).
There are, I think, two questions hidden in your question:
Why do I feel so? Because I write software for all three major platforms, and shipping software that just works out of the box on Linux is, simply, a pain. Now if you know something I don't about packaging software on Linux, which I am entirely willing to believe, mind, now would be a great time to share.
Now, why do I reason so, which is very much not the same thing? Mostly because of the issues brought up in the Autopackage page which I linked to and which I doubt you read, and because I know the culture attached to Linux -- and as I said in my initial post, the issue is at heart one of culture, not a technical one. If we set our hearts on making it happen, then it would probably not be too terribly complicated, technically speaking. And yet what do we see happening instead? People posting on Slashdot about how it needn't happen, citing examples that fall exactly within the realm of pain-in-the-ass that was described in the parent post.
Because it's not about whether it's feasible, dear. Of course it's feasible. But it is still complicated, costly, it generally requires hacks and shipping different versions for different flavours of Linux or, in the Java VM's case, not linking against ANY Linux library beside libc.
So, yes, a few companies with a vested interest in Linux go out of their way to support Linux despite the hurdles. And that's very, very much not the same thing as making it straightforward enough, that neutral third parties without a vested interest in Linux will find it cost-effective to support our platform.
And the only, the only thing that we can do about this issue is try to bring awareness of it among our own ranks.
Will you help me?
...how long are we going to have to wait...?
.deb, really) in the hope of covering a sufficient user base, while hoping it won't completely break next time some distro upgrades to libwhatever.so.52; or you can try to get your software into the package repositories of all the major distributions (and thus become entirely dependant on the goodwill of each distro for access to your software); or you can try to package the software your own way and hope for the best (that's what Loki did for their games, for instance), which is still vastly suboptimal because it's a lot of additional work for you and you still have no guarantee it'll work well, due to countless issues, the least of which not being that ELF has real, real issues where it comes to binary compatibility. Oh, and yeah, you can also just ship the sources in a tarball, hereby reducing your user base to the demographic of Linux geeks.
.debs | use .rpms | fork your own distro?"
Well, it's something I've been thinking a lot over the last years, and I'd like to share my thinking with you lot:
At this point, I don't think we're going to have a major breakthrough until Linux becomes third-party friendly.
Let me explain.
At the moment, the whole experience of using a Linux distribution is balanced between two parties: the user, and the developers of the distro. Linux distributions in general have come a LONG way in minding the user's convenience, but I am still not sure this will suffice.
Because the success of other platforms (well, Windows, alright) doesn't boil down to user friendliness, I think that much is clear by now. No, what made its success is that it fosters a rich environment of third parties -- entities that are neither the OS maker nor the user, yet benefits both.
Something that is still a long way from penetrating the Linux culture, I think.
At this point, let's imagine you're a third party (and as such, not particularly involved in the Linux world as such -- to you it's just a platform among others) and you wish to ship your software for Linux. What are your options? Well, and that's assuming you're even going to bother trying to figure out the whole mess, you can: try to ship various packages (.rpm and
Compare with Windows: just put the binaries in a ZIP file or an installer. Done.
And let us not mention the issue of drivers. At this point, shipping a driver for Linux, when you're a neutral hardware maker third party, involves either sending the kernel maintainers your code and hope they'll consent to include it in the main kernel tree at some unknown point in the future, or ship some manner of hack that will try to compile your driver against the installed kernel, which will simply not work if the compiler, or even the right kernel headers, aren't already installed. (To be fair, the initiative that was recently spoken of on Slashdot, about some company developing Linux drivers for third parties for free, is interesting and might improve the situation lots.)
In short: when you're a third party, supporting Linux is generally not worth the pain.
This is a very bad situation for us, because we need hardware makers to support our platform, so there isn't an ongoing gap of weeks or months between the release of bleeding edge hardware and its support on Linux, and there is just plain not enough of us to reproduce the functionality of all the software third parties are making for other platforms
Admittedly, projects like Klik and Autopackage are a step in the right direction, but isn't it too little and perhaps even too late? I don't know.
Because the main, the core issue here is not technical.
The core issue is that when you discuss something like Autopackage, the response typically amounts to "Why don't you use
And this, my friends, is why I've lost hopes of seeing the Linux desktop go mainstream.
Hopefully the future will prove me wrong, though.
Give us a standard that actually delivers enough power that you don't need an additional power cord for just about every other device already... :/
> And let me note that in France, ID is nationally issued and you're required to carry it
> everywhere.
Uh, no.
There is such a thing as a national ID card, but having one is optional since 1955 (and free since 1998). As far as I can tell, you are only to carry a driving license to your name when at the wheel, and you have to be able to prove you're not an illegal immigrant -- hence your working visa.
Mind, I could write whole BOOKS on the ways in which France sucks, so don't take the above wrong; I just thought I'd point out some factually wrong element in your otherwise interesting comment.
Several things there.
1) De-facto standards, where a given arbitrary product is the reference, and codified standards, as described for open implementation, are VASTLY different things. Can you tell why? (Here's a hint: the answer contains the words 'lock-in'. I'll let you ponder that while ruing the lack of Firefox and XUL user base.)
2) However, reference implementations are a good thing, because they, as you rightly point out, help developers. Not providing a reference implementation of CSS is possibly the biggest mistake the W3C made.
3) In a perfect world, you'd be using just whatever the hell you want and it would make no matter. Gecko lock-in is not much better than IE lock-in. (Case in point: browse the commit logs of other browsers and count how many entries there are that go, "Emulate Firefox bug such-and-such so as to display somesite.com correctly". Seriously.)
And lastly,
4) I am slightly annoyed that you seem to assume I don't know about Web development. Because, meanwhile, in the real world, our issue tracking system is littered with tickets that read something like:
"Dear Mr. Important-customer-at-huge-company,
The issue you report looks like a bug in Internet Explorer. We'll allocate developer ressources to implement a work around for the next revision of the product. Kind regards, etc..."
This costs money. This costs resources that could be allocated to building better mousetraps, to make awesome shit, to create stuff to be proud of and to drive things ahead. Instead... Working in this field today is trying to build castles on swamps, and it's a daily struggle to not cave in and just sell shaky wooden shacks (painted cheap gold as per marketing's instructions) like the rest of 'em.
And this is not something I can do anything about.
However, you can.
Will you, in all consciousness, make the choice to be part of the problem? That choice is yours and yours only.
Actually, the KDE guys (in particular, the ever awesome Zack Rusin) are working with the WebKit people in order to make WebKit work on the same rendering canvas that KDE uses (namely Qt's QPainterDevice). So Konqueror 4 will most likely use WebKit itself, rather than KHTML, on all three platforms, Linux, Windows and Mac.
... Just so long as WebKit doesn't end up deviating from the standards for whichever reason, anyway. Y'know. (Yeah, I've been in this industry too long to remain optimistic, I know.)
The reason why this is such great news is that this could possibly make WebKit, one of the most standard compliant engines out there, the number one option after IE (alongside with Gecko), which will hopefully prompt Web developers to, at last, respect the standards as the basics for any Web development.
You know, that's both the most insightful and the most disturbing metaphor I've ever heard about this issue thus far.
I've long thought that distros generally prefer GNOME (probably for license and looks-better-out-of-the-box reasons) but users have different criteria about desktop environment choices (looks better after tweaking, does everything you want, fast, and otherwise remains very much out of your way, etc). It is interesting that distros and users should have wants driving them to opposite choices, though, and probably goes to show that Linux has already spread far, far beyond the demographic of geeks that take part in its development.
1) Procmail can actually detect mail sent from daemons.
2) It matters not that you give out many different addresses to different entities so long as you keep only a small list of addresses to SEND mail.
Based on this, you can tell procmail to filter anything that comes form a daemon (bounces, in particular) and is not addressed to one of your sender addresses.
Example
Once done, investigate SPF, and have an SPF entry added to your domain. This makes your domain much less interesting to use for return addresses, and spammers are likelier to stop using it when they take notice (which might take a few months, be patient).
Worked for me anyway. (Worked damn fine, actually.)
Holy shit. The cheek of it. "Until then, expect some elaborately spun responses from Sony's competitors." Really.
Reality check: Sony sold 165,000 PS3 and the rest are already sitting on shelves. Nintendo shipped how many times that many Wii? and is still sold out. How the HELL is that good news for Sony? Someone please explain me, I really don't understand...
> There are quite a few people used to the old world where a string was interchangeable with a
> vector of 8 bit bytes
No. No, no, no. NO. Please, no. Seriously. This is bad. A LOT of damage happens because people can't be bothered to spend the 10 minutes it takes to learn the basics of Unicode. It's easy. I don't always think very highly of what Joel Spolsky writes, but his introduction to Unicode is an ABSOLUTE must-read.
Seriously. Strings are NOT interchangeable with byte arrays. EVER. Without an encoding information, a byte array can represent a wild number of different strings. Without an encoding information, you can't even tell where the string that the byte array represents ends! This is one of my pet peeves, really -- pretending that byte arrays and strings are equivalent is on the same level of professionalism as pretending that the data won't ever be larger than your buffer. Ignoring issues that bother you don't make them go away.
Short answer: various things, compilation to bytecode before execution (I thought it was the case in the current interpreter, but might have been mistaken), etc.
Slightly less short answer: if I'm not mistaken, YARV includes a JIT compiler, similar to what Psyco does in the Python world. Psyco has been known to accelerate code execution up to 100x times, so I'd expect YARV to be even faster than this benchmark shows when it's stabilized.
Okay, I generally try not to make snarky comments, but, with my apologies, please allow me to indulge briefly. :)
:)
:)
:)
> With PHP, it's simple -- your test machine is probably set up already, and your deployment
> webserver almost certainly is.
<snark>Are you FUCKING kidding me?</snark>
(Golly, I already feel better.)
Now please allow me to expand.
Deploying for PHP is an insane pain in the ass. PHP breaks compatibility at every turn on the wind (fun fact: the product I'm paid to deploy for a large company right now doesn't run on the very latest PHP... and the previous version has since had security holes discovered, joy). PHP's behavior depends strongly on the host configuration, which may vary wildly and to which you may not even have access. Availability of certain features is conditioned by how PHP was compiled, which you might have no control on. PHP is not thread-safe and may wreck your data on certain Apache configurations. And so on, and so on.
Since Python was brought up in this thread, let's compare. Python has an API called WSGI that plugs into pages or frameworks on the client side, and Web servers on the server side, and any WSGI-compliant server method and framework will do. All the Python-based frameworks, Django, TurboGears, Web.py, Pylons, etc, support WSGI. Apache with mod_python or CGI or FastCGI or FCGID support WSGI. Lighttpd has a WSGI module, I believe. Whatever is available for you will do for a Python framework so long as there's a WSGI interface for it, and there's a WSGI interface for pretty much everything these days (although some googling might be in order in some cases). Recently, I deployed one of the largest Python frameworks under a very restricted platform that only allowed CGI: it worked just fine. In fact, I imagine it shouldn't be exceedingly hard to code a small PHP handler that would delegate calls to WSGI, which would allow you to deploy a Python framework wherever PHP is installed. Now that would be fun.
Also, Python has a standard library that can be counted on everywhere it's available, and I had never before understood how much of a boon that can be, honestly. It's also thread-safe (although it does pay a price for this safety -- when you know that price and when it matters and when it doesn't, be proud of yourself, because you'll then know one of that tool's flaws, and knowing that is the beginning of mastery).
Mind, I'm not telling you to drop everything and start courting snakes right away, because that's not my fucking call -- it's yours. Do NOT switch tools if you don't know, personally, WHY you should; everybody will be happier in the end that way (but I do encourage you to learn new tools when you can and what they're good for and why they're good; it's healthy for the mind). But I find your comment interesting, because it implicitly connected an unknown (deploying under Python) with a difficulty comparatively to your current known way, regardless of the inherent flaws of that way. Interesting, how the mind works, isn't it?
This being said, dropping an 'hello world' in some directory and having it work right away is something PHP still does better; in fact, it's simply great at it. It's when you start using non-trivial functionalities that things go downhill.
Anyway. As a conclusion: do me a favor, forget Python for at least a day, and go learn Ruby instead at first. Why? Because I would like you to learn why you're using the tools you are, and listening to some random dude on the Net about some random language is quite probably not how you'll achieve that.
Thanks for reading! (And sorry, I tend to be a bit verbose, I know.)
Alright, I'm a little busy right now so I won't go into as much detail as I'd like, but here are the basics as far as I understand them.
:) Hopefully other people will have more details to give you.
1) Design patterns still apply. More than ever, actually. If you've not read the GoF, it features a pretty advanced example centered on the design of a rich text editor. You will probably want to dive deeply into the workings of the Model-View-Controller pattern and the related design constructs. The MVC pattern is not the be all and end all of GUI design, and there are many cases where the articulation between View and Controller
2) You may not now it yet, but you want loose coupling. Loose coupling means that, essentially, when a widget's state change, it will report on that change, and some interested party will be notified about it, and neither will have to know anything about the other. Many toolkit nowadays come with good signal and slot mechanisms to implement loose coupling. Understand them, and use them. If you find the sender of a signal and the receiving slot need to know about each other, you may want to go back to the drawing board as suggested in point #1 above; it is usually not necessary.
Conceiving GUIs is not all about the underlying software architecture, though; a good chunk of the work of making great interfaces is in the designing of the GUIs themselves (which is why you want loose coupling -- you WILL have to be flexible against changes as you experiment). I will let others fill you in about that. Quickly: read usability guidelines and get a feel for why they suggest what they suggest. Align your widgets! NetBeans is good for this, IIRC. Use GUI designer tools, experiment more.
That's all I can think of off the top of my head, but there's already a lot for you to chew in there.
All in all, it boils down to the usual rules of engineering: the second rule is to know what works, and the first rule is to know why it works.
Example to find all links in a document:Yes, it's that simple. For an URL opener that also handles proxies, cookies, HTTP auth, SSL and so on, look into the urllib2 module that ships natively with Python.
Why?
Well, a well-written code -- which is also a mandatory thing, to me -- will make it very clear WHAT is being done.
A comment's purpose is different: comments should tell you WHY it's being done this way.
Example of a typical bad comment:And a better comment:Depending on how conscientious you are, you might even want to explain why it's BUF_SIZE-1 and not BUF_SIZE. Yes, of course, YOU know. Right now. The next person peeking at the code -- which might be yourself, in three years and in a hurry -- might not, though.
Otherwise -- good post. Thanks for posting.
HaydnH,
I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulnerable to the bugs of the previous release until you're done; or you don't intercept it, and have your production sites break in various ways.
(I am not going to go into why the very concept of a nl2br() function is fundamentally broken; that's matter for another time.)
It may be that you like PHP for your own reasons, and that's all good and fair, but please, please don't try to brush this kind of serious issues under the carpet. Doing so is doing a disservice to your language. It's only by expecting its developpers to do things right that you'll incite them to move away from the bad practice that are giving a language you may be fond of such a bad reputation.