My roommate laments my lack of musical taste (or at least me being 'not picky' about what I listen to) because while I listen to bands that she likes -- Coldplay, Crowded House, Barenaked Ladies, classical music, etc. -- I also listen to stuff she doesn't care for, like Finnish opera-influenced metal (Nightwish), 'bad' British hair rock (Ten), 'bad' Japanese hair rock (X-Japan), J-pop, 'annoyingly repetitive' soundtracks (Pirates of the Caribbean), etc.
I let it roll off me, 'cause honestly, if I like Nightwish or I like Ten or I like X-Japan or I happen to feel like listening to the repetitive but very dramatic style of soundtrack that Hans Zimmer creates, is that anyone's business but my own? I listen to what I enjoy, and I listen to it because I enjoy it. Just because someone else doesn't appreciate Ten's 'Far Beyond the World' or 'Name of the Rose' doesn't mean I can't...:)
Trillian Pro 2.0 users can download a patch already for Yahoo from the members section. It's been running fine for me and for other Trillian Pro users since it was released. It shouldn't be too long before the older versions of Trillian also have patches.
I expect Gaim, the Jabber Yahoo transports, and other systems will be up and running again within about 24 hours, too.:)
Many businesses are 'work-at-will' businesses, meaning both that the employee or the employer can terminate the employment contract at any time.
IANAL, but a quick search for 'work-at-will' via Google produced links by people who are, which explain a little about work-at-will and also how some litigation has made work-at-will a little less 'you can be fired whenever for whatever reason'. But in general, you have less protection as an at-will employee than you might otherwise, and most employment contracts are work-at-will. So they likely could indeed fire him, though he might have grounds to challenge his dismissal.
Yes, being an Objective-C user, I know some dynamic-typed languages are compiled rather than interpreted. (Of course, for all that I really like its object model, ObjC is a pretty lousy example as it inherits all of C's flaws.):)
Though, also being an ObjC and Java user, I dispute the claim that garbage collection is a silver bullet for memory leaks. It's possible to mess up reference counts just as badly as malloc/free pairing. GC does nail double frees, and it makes memory leaks less likely, but it's still not a silver bullet to solve/all/ memory allocation related problems.
My point with C, also, was not specifically to stress C itself as still being useful but lower-level languages. Objective-C, for instance, is a great applications language. However, the runtime library which gives it many of the 'silver-bullet' features such as runtime garbage collection is a resource that needs to be taken into account; I'd never want to write a device driver in Objective C while linking in the support libraries and classes to provide runtime garbage collection, for instance.
Perhaps a/better/ way to put that part of my point is that systems which have runtime solutions to problems -- not just interpreted languages -- are great for the application layer, but low-level things, such as device drivers and system kernels, are more likely to be written in languages where you do not have a required support library to provide the features. This is a generalization, yes. Slashdot specializes in generalizations.;)
So while C itself may not last forever, and while there are legitimately way better solutions for modern application programming, I think there will always be a place for/some/ language and compiler which requires the programmer to do most of the work. I.e., I doubt we'll ever see someone writing video card drivers in Visual Basic.
Very true, that runtime type checking is an element of strong typing. However, again, I will note that an interpreter/can/ catch things which are harder at runtime; I am not merely discussing runtime type checking.
Assuming that runtime type checking is the the 'silver bullet' for fixing programming bugs is as much a fallacy as the original poster's assumption that Java and C# solve all programming languages.
It's not a simple and straightforward 'there is a single solution to everything' issue. To discuss the myriad potential problems, how particular language definitions can eliminate some, and how implementations of programming languages can eliminate others, and how still others can only be dealt with by the programmer, could fill a book or provide a topic for a website.
Wait, that was the original topic, and the original poster's claim was that Java and C# solve all your problems for you and therefore there's no need for such a website. This is not true. Some things -- such as buffer overruns -- are more easily solved in interpreted systems (or, being fair, runtime systems that do far, far more stringent length checking), but nothing -- not interpreted systems, not strongly typed languages, not some magical library you link against -- will solve all your problems for you.
I stand by my statement that no language, no compiler design, is a silver bullet that solves everything. I stand by my statement that the original poster is incorrect, and Java/C# are not the solution to everything; C still has its place, especially in low-level programming.
Argue terminology all you want with me, and I'll concede that I could've been clearer/more accurate on the terms I used, but I'm not going to be swayed enough to say that C# or Java solves all ills. I like Java, but it's not a genie.:)
Perhaps I misunderstood the original poster's point? His post has been moderated right off the comments list, unfortunately, so my original reply has rather lost its context. At this point, the original point I was trying to make has unfortunately been completely lost in a discussion of terminology, so I'll just bow out of the conversation.:/
I think this is perhaps a difference in terminology; I apologize for the confusion.:)
You're using language in the strictly correct sense. I.e., a language is solely the parser/lexer definition, and what's done with it afterwards is the rest of the compiler implementation. I.e., GCJ, javac, guavac and others are all 'Java', despite differing backend implementations.
I'm using language incorrectly, but largely out of habit trying to deal with folks who are not engineer-oriented. (After about the fourty-seventh time you've tried to explain the difference between 'language', 'compiler' and 'interpreter', you sort of give up.) And let's be honest, there are some languages -- such as Perl and, to be honest, Java -- where the most commonly-used implementations/are/ interpreted.
To rephrase in an attempt to bring this back on track...
The original poster I replied to made the claim that no one should use older languages, and that everyone should use Java and C# because they solved all problems.
My reply was intended to state that interpreted bytecode systems such as Sun's JVM implementation, the Perl interpreter most widely used, the Python interpreter, and others have some security benefits -- as the original poster I responded to claimed -- but that they do not solve all problems. The interpreted nature of the bytecode used by these interpreters allows the interpreter, while translating the bytecode, to perform at-runtime checks which are harder -- but not impossible -- to do in precompiled code, but it is not a magical solution to every problem. Java will not, for instance, analyze a encryption routine for you and determine if it's cryptographically secure.
Similarly, I would claim that interpreted systems -- such as Sun's JVM, the Python VM, the Perl interpreter and so on -- are not ideal for all applications, because an interpreted system is inefficient. Indeed, some of the inefficiency is caused by the same 'guard against security' which the first poster so lauded.
So, the original poster's apparent point was: Java and C# catch all your errors for you and solve all security problems, everyone should just use those.
My point in reply was: interpreted systems can do runtime error-checking for you in an effective way, but there are downsides.
Hopefully that makes the point I was originally trying to get across clearer, without muddying it in terminology.
(And for the record...if you want to nitpick that javac's a compiler that just happens to target a bytecode, I'm going to assume you only want to argue terminology rather than my actual, original point, and will not play. Yes, javac is a compiler that targets a bytecode. The bytecode is then interpreted by a VM, so I call the javac/JVM combination an interpreted system, dammit.):)
Very true, but the most common implementations of the Java, C#, Python, etc. languages are interpreted. Your average Java developer is, at least in my experience, not using GCJ.
Perhaps I misunderstood the original post which I was replying to, but the poster seemed to be making the point that Java and C# -- being interpreted -- fixed all security problems. I concede that an interpreted language fixes some problems because the nature of interpreted code makes it possible to catch some things at runtime (a benefit you lose to some extent when you use tools like GCJ), but I dispute that it fixes all security holes, or that Java and C# are suitable languages for all situations.
I stand by my statement that I would not want to write a low level VXD device driver in Java. (I'd prefer not to write one in C, either, but that's due to a general dislike of the Windows driver system, and neither here nor there.):)
It's more than just speed issues. Interpreted languages have better runtime checking and thus can avoid things like buffer overruns, yes. That's great for a lot of things, don't get me wrong. For backend programs, Java is an absolutely brilliant language, as it encourages some much better object-oriented design philosophies. Even Objective C handles some runtime checking far better than C or C++, though as it is a set of extensions to C it suffers from the same weaknesses in C code.
But what is the JVM written in? I guarantee you it isn't Java.:) Last I checked, the original Java Virtual Machine was written in C...after all, you can't run Java bytecode without something to interpret it. Similarly, I bet you most Just-in-Time Java compiler/interpreters are also written in C or C++. Even the programs which take Java code and turn it into a binary executable likely are linking it against a library which was written in C or C++.
Similarly, at my old job, I had to write low-level drivers for PCI hardware we were developing. Did I get to write these drivers in Java or C#? Of course not... you can't write low-level hardware calls such as Windows VXD files in an interpreted language; it'd really kill the performance of a system.
Just for a moment try to imagine someone writing, say, a new video driver for the Linux kernel in Python, or rewriting XFree86 in Java.
Ow.:)
Moreover, while Java makes it a great deal harder to, say, create a remote root exploit through a buffer overrun, it does not automatically fix problems of, say, cryptographic strength. Creating an encryption algorithm for some vital data which can be easily broken is as much a security hole and a flaw as a buffer overrun.
So while you're correct in some places -- Java and Python and C# and other interpreted languages that can do more stringent runtime checking of things really/do/ solve some problems which traditional lower-level languages are more vulnerable too -- modern interpreted are not a panacea for all programming ills. They aren't suitable for all types of programming, and even for the ones they are well-suited for, they don't automatically solve all security issues.
In general, the lower-level the language, the more easily you can mess it up; ASM is even easier to fry things in than C or C++. It becomes a tradeoff, with the lower-level languages giving you progressively greater efficiency and the ability to access things 'down on the metal', with higher level languages -- while slower and more abstracted -- able to shield you from more mistakes, and more portable between situations.
Each has their place. I wouldn't want to write a web-client that ran database queries in ASM, but Java works great. Conversely, I wouldn't want to write a driver for an AGP graphics card in Python, but ASM or C works pretty well right there.;)
Actually, to be fair, Grave of the Fireflies is one of the very few 'non-standard' anime that people/are/ more likely to have heard of; it's been pushed through enough art-house circuits that it's at least slightly more likely to be known.
That does not, however, negate the general point you made; to build on the terminology in the post I made earlier in this thread, an overabundance of chaff in a genre does turn people off from it as it burns them on out looking for the wheat buried among it.
With 8 million 'panty-shot' anime or recycled-plot series coming out, films like Whisper of the Heart are sadly likely to be overlooked. Heck, even the really beautiful and engrossing Twelve Kingdoms, despite getting translated, is likely going to not get a great deal of notice.
The same is true with books, as well; I'm reading an excellent book by a relative newcomer author, Sarah Ash, but I'll bet you that many people -- having been burned by bad books by newcomers to the fantasy genre -- will skip this one and stick to the authors they already know and like. And that's a shame, because -- while I only just picked up the book, and am only a few chapters in -- so far 'Lord of Snow and Shadows' is a surprisingly engrossing and well-written book.
And really, that's what's to be lamented. The push by publishers and distributors to focus on quantity over quality, to the point that until you've read -- or gone looking for reviews -- a book or watched an anime or whatever, you can't tell the chaff from the wheat. Choice is good, but it does burn some people out and make them stick to the authors/series/works/whatever that they know, not risking the chaff.
Not only that, but many genres suffer from dilution. When there's a dozen people writing in a genre or producing for it, it's far easier to separate the wheat from the chaff. I think today, there's more wheat, but there's also more chaff.
Today when I go to the bookstore and look at the science-fiction section, I see all these new books, half of which are by authors I've never heard of before. Brand-new, first-time writer, or someone who's just not gotten coverage, or whatever. And every book has testimonials on the cover, someone saying the author is 'The most promising new writer to enter the genre since...' or whatever. So really, the only way to know what's good is to read it yourself... and since there's so much out there these days, there's much more chaff to sort through to find the wheat.
I think it's true with anime, too -- the growing popularity over the past few years has made a number of anime pop up which, honestly, aren't all that worthy, to reference the Miyazaki quote. It's true of almost any medium of fiction and expression when the field becomes crowded; it's not necessarily that the number of worthy things has decreased, but that the number of things/overall/ has increased.
That said, it's nice to see M'Oak get some linkage. Maybe it'll spur a few more T&K fans.:)
No. And hey, if GPL is your determining feature, then more power to you; GAIM's a great package, too. Sean and the others are cool folks. I happen to think the friendly rivalry between the two only makes both products better by driving us to cheerily outdo each other's new additions, and we have both exceptioned our licenses to contribute code to each other before when needed to help out -- for instance, we've given MSN code to GAIM, and they gave us some code for Yahoo.
There are also legitimate reasons for Trillian's closed status; there are things we couldn't do in GPL, because partners who want custom versions of Trillian have non-GPL'd libraries they want to put in, stuff like that. The GPL license/is/ wonky in that area at times, and putting an application under LGPL rather than GPL tends to arouse the Wrath of The Masses. We might've been able to get away with Artistic, but then you don't have the FSF legal council to back you up if your code is stolen.:(
I happen to like open source and use it for all my own personal projects, but it's not necessarily the be-all and end-all of software development; both open and closed source have their advantages, and both have their place. Both also have their own flaws, their monsters and boogiemen. It was Scott and Kevin's call, and in the end they preferred the closed-source 'monsters' they knew to the open source ones that they didn't.:)
Ironically, I find Jabber a much more simple/straightforward protocol than SIP/SIMPLE. Especially as Jabber in its present form can be used as a full-featured instant messaging packages, where SIMPLE is not far enough along, and the only SIMPLE implementations therefore rely on proprietary extensions to flesh it out.
This isn't a troll; I do honestly think SIP and SIMPLE have their place. SIP is way more suited to negotiating multimedia streams than XMPP/Jabber ever will be. SIMPLE strikes me as much better for handling 'conference call' type situations without relying on Jabber's groupchat implementation, as well.
But SIMPLE just ain't here yet...it's a promising base for a lot of things, and the pledge of various instant messaging networks to support it is great...but it's still under construction. Jabber/is/ here right now, and easy to implement, and functional today, and despite some of its own rough edges it's always felt a lot simpler to work with than SIMPLE. XML's pretty darn easy to parse.:)
Honestly, on the day that all the messaging networks get together and agree on a standard, I'm fairly sure my co-workers and I will be dancing with joy. There's an element of cool challenge to hacking apart the AIM protocol, the ICQ protocol and so on. But it's also a monumental headache and time-consuming task, and the only reason to do it is because right now, there/is/ a need for cross-network clients.
On the day that cross-network clients become unnecessary, our job of making a good central communications client becomes a lot easier, because we don't have to spend so much time making sure so many different protocols all work!:)
Well, to be fair, there are some definite wackinesses in jabberd 1.4.2 when you're running a really high-volume server, like if you ran jabber.org using the free server.
However, most people are not going to be running 100,000 user servers using the free server version. And I've run a test-server for doing the Jabber work with Trillian for several months now, and not blown it up at all.:)
Some Jabber clients have end-to-end encryption, but the standard on that is still a little shaky. It's basically just a PGP signing and encryption method.
Best Jabber client for Windows presently really depends on what you need and want. Jabberstudio.org has a lot of good ones. Psi is an excellent one, RhymBox is a very clean and easy-to-use one, Exodus has a very plain and un-glitzy UI, but tends to support damned near every part of the protocol that pgm can cram into it. In my opinion, Psi's a good choice for folks coming from the Linux realm, RhymBox is a good choice for Windows-only folks, and Exodus is a great tool if you're a Jabber dev who wants to poke and things (and periodically blow up Exodus by sending it malformed XML while testing).;)
No, we just didn't include Jabber earlier because AIM, ICQ, MSN and Yahoo are a bitch to write for, and the time and energy needed to go into getting those right first. It's called prioritization of limited manpower (or, in my case, womanpower).:)
The Jabber portion's working in the internal alpha builds, and the next version of Trillian does have Jabber support. While I'm not as active in the Jabber dev community at the moment since we're hunkered down debugging and cleaning up to get the next release out, we're pretty devoted to the Jabber community as well. I've been an active participant in standards discussions and revising and authoring JEPs, and we have some long-term plans for Trillian regarding Jabber which are pretty beneficial to both Trillian and Jabber.
No. This 'problem' is not what we've solved with Trillian. The problem we aim to solve with Trillian is 'god, we need a way to have multiple IM and information clients in a single executable, because this is insane.' The problem Jabber aims to solve is 'my god, instant messaging is important to many things, we need an open standard so people can write software and set up servers as they need, without being hooked into proprietary stuff.'
I'm one of the Trillian developers; trust me on this.
Jabber picks up multiple network support on server-side as a benefit of the modular design of the server and extensible nature of the protocol. HOWEVER. The Jabber development community will tell you that the transports are not intended as an all-in-one solution; they're just there to ease the transition to Jabber, so you don't have to lose touch with existing contacts while you're urging them over to Jabber as well. The transports are, in fact, the bane of many a Jabber dev who finds people think of Jabber as a Trillian equivalent -- i.e., looking at it as a way to get onto the legacy networks and not looking at the Jabber protocol and Jabber contacts themselves.
And yes, as noted, Trillian gets Jabber in our next release.:)
IRC servers can only connect between specific servers -- think of it like a tree. If you knock off a 'hub' server -- a branch -- then all the leaves off that hub are gone.
Jabber, however, is more like e-mail. Any Jabber server can talk to any other Jabber server. Which, yes, like with e-mail means one specific Jabber server might be down, but like e-mail, it means the entire network doesn't fold.
Would you really want to see a movie like 'How To Lose a Guy in 10 Days' or 'What A Girl Wants'?
...yes? 'What A Girl Wants' was actually quite funny. High cinema it was not (but let's be honest, no matter how good an actor Chow Yun-Fat is, neither is Bulletproof Monk), but it was enjoyable...and we got to see Colin Firth in leather pants, which is always a plus!
Then again, most of the Slashdot audience may admittedly not be quite as inclined to appreciate things such as Colin Firth in leather pants as those of my gender are. (Mmmm. Hot British guy...);)
And 'Whisper' is one of my favorite Ghibli films too, yes. Miyazaki and Kondou had not worked together as a duo since they were younger, and it's a shame they didn't do more together.
Miyazaki also worked on Whisper, but Kondou was the director. It was fulfilling a promise they made each other when they were much younger to make a film like that; it was a film they'd both wanted to make for a very, very long time.
Miyazaki's eulogy for his friend is very touching; it can be found linked from the Kondou page on Nausicaa.net...
...though bear with slow response, as Nausicaa.net is already pretty well experiencing the Slashdot effect. My traffic-shaping rules are helping the site hold its own, but you may have to tolerate sluggish reply at the moment.:)
Whisper of the Heart was directed by Yoshifumi Kondou, who was considered by many to be Miyazaki's protege and eventual successor. After Kondou's amazing work on his directorial debut (Whisper), Miyazaki planned to retire and turn over the helm to Kondou.
Tragically, Kondou died in January 1998 of an aneurysm, never having a chance to direct a second film.
The great cop out for open source programmers is the position that they don't want lots of people installing and using their software. If you didn't want people to use it, why did you publicly release it?
Generally? Because you thought it might be useful. The key is, as you pointed out, they may not expect/lots/ of people installing and using their software.
I've been in the position of creating a package that was useful to me, tossing it out there and figuring one or two other folks might use it...and then discovering 'dear god in heaven, I'm getting 200 support e-mails about this thing a day! Aaaugh!' and starting to pull my hair out. In a way, it's flattering because 'gosh, it was useful' but in a way it's a bit overwhelming if, say, you only have one or two people writing a package and suddenly you have a flood of support requests.:)
Slashdot Mirror
My roommate laments my lack of musical taste (or at least me being 'not picky' about what I listen to) because while I listen to bands that she likes -- Coldplay, Crowded House, Barenaked Ladies, classical music, etc. -- I also listen to stuff she doesn't care for, like Finnish opera-influenced metal (Nightwish), 'bad' British hair rock (Ten), 'bad' Japanese hair rock (X-Japan), J-pop, 'annoyingly repetitive' soundtracks (Pirates of the Caribbean), etc.
:)
I let it roll off me, 'cause honestly, if I like Nightwish or I like Ten or I like X-Japan or I happen to feel like listening to the repetitive but very dramatic style of soundtrack that Hans Zimmer creates, is that anyone's business but my own? I listen to what I enjoy, and I listen to it because I enjoy it. Just because someone else doesn't appreciate Ten's 'Far Beyond the World' or 'Name of the Rose' doesn't mean I can't...
Trillian Pro 2.0 users can download a patch already for Yahoo from the members section. It's been running fine for me and for other Trillian Pro users since it was released. It shouldn't be too long before the older versions of Trillian also have patches.
:)
I expect Gaim, the Jabber Yahoo transports, and other systems will be up and running again within about 24 hours, too.
Many businesses are 'work-at-will' businesses, meaning both that the employee or the employer can terminate the employment contract at any time.
m l :)
IANAL, but a quick search for 'work-at-will' via Google produced links by people who are, which explain a little about work-at-will and also how some litigation has made work-at-will a little less 'you can be fired whenever for whatever reason'. But in general, you have less protection as an at-will employee than you might otherwise, and most employment contracts are work-at-will. So they likely could indeed fire him, though he might have grounds to challenge his dismissal.
One example:
http://writ.news.findlaw.com/grossman/20010911.ht
Yes, being an Objective-C user, I know some dynamic-typed languages are compiled rather than interpreted. (Of course, for all that I really like its object model, ObjC is a pretty lousy example as it inherits all of C's flaws.) :)
/all/ memory allocation related problems.
/better/ way to put that part of my point is that systems which have runtime solutions to problems -- not just interpreted languages -- are great for the application layer, but low-level things, such as device drivers and system kernels, are more likely to be written in languages where you do not have a required support library to provide the features. This is a generalization, yes. Slashdot specializes in generalizations. ;)
/some/ language and compiler which requires the programmer to do most of the work. I.e., I doubt we'll ever see someone writing video card drivers in Visual Basic.
Though, also being an ObjC and Java user, I dispute the claim that garbage collection is a silver bullet for memory leaks. It's possible to mess up reference counts just as badly as malloc/free pairing. GC does nail double frees, and it makes memory leaks less likely, but it's still not a silver bullet to solve
My point with C, also, was not specifically to stress C itself as still being useful but lower-level languages. Objective-C, for instance, is a great applications language. However, the runtime library which gives it many of the 'silver-bullet' features such as runtime garbage collection is a resource that needs to be taken into account; I'd never want to write a device driver in Objective C while linking in the support libraries and classes to provide runtime garbage collection, for instance.
Perhaps a
So while C itself may not last forever, and while there are legitimately way better solutions for modern application programming, I think there will always be a place for
Very true, that runtime type checking is an element of strong typing. However, again, I will note that an interpreter /can/ catch things which are harder at runtime; I am not merely discussing runtime type checking.
:)
:/
Assuming that runtime type checking is the the 'silver bullet' for fixing programming bugs is as much a fallacy as the original poster's assumption that Java and C# solve all programming languages.
It's not a simple and straightforward 'there is a single solution to everything' issue. To discuss the myriad potential problems, how particular language definitions can eliminate some, and how implementations of programming languages can eliminate others, and how still others can only be dealt with by the programmer, could fill a book or provide a topic for a website.
Wait, that was the original topic, and the original poster's claim was that Java and C# solve all your problems for you and therefore there's no need for such a website. This is not true. Some things -- such as buffer overruns -- are more easily solved in interpreted systems (or, being fair, runtime systems that do far, far more stringent length checking), but nothing -- not interpreted systems, not strongly typed languages, not some magical library you link against -- will solve all your problems for you.
I stand by my statement that no language, no compiler design, is a silver bullet that solves everything. I stand by my statement that the original poster is incorrect, and Java/C# are not the solution to everything; C still has its place, especially in low-level programming.
Argue terminology all you want with me, and I'll concede that I could've been clearer/more accurate on the terms I used, but I'm not going to be swayed enough to say that C# or Java solves all ills. I like Java, but it's not a genie.
Perhaps I misunderstood the original poster's point? His post has been moderated right off the comments list, unfortunately, so my original reply has rather lost its context. At this point, the original point I was trying to make has unfortunately been completely lost in a discussion of terminology, so I'll just bow out of the conversation.
I think this is perhaps a difference in terminology; I apologize for the confusion. :)
/are/ interpreted.
:)
You're using language in the strictly correct sense. I.e., a language is solely the parser/lexer definition, and what's done with it afterwards is the rest of the compiler implementation. I.e., GCJ, javac, guavac and others are all 'Java', despite differing backend implementations.
I'm using language incorrectly, but largely out of habit trying to deal with folks who are not engineer-oriented. (After about the fourty-seventh time you've tried to explain the difference between 'language', 'compiler' and 'interpreter', you sort of give up.) And let's be honest, there are some languages -- such as Perl and, to be honest, Java -- where the most commonly-used implementations
To rephrase in an attempt to bring this back on track...
The original poster I replied to made the claim that no one should use older languages, and that everyone should use Java and C# because they solved all problems.
My reply was intended to state that interpreted bytecode systems such as Sun's JVM implementation, the Perl interpreter most widely used, the Python interpreter, and others have some security benefits -- as the original poster I responded to claimed -- but that they do not solve all problems. The interpreted nature of the bytecode used by these interpreters allows the interpreter, while translating the bytecode, to perform at-runtime checks which are harder -- but not impossible -- to do in precompiled code, but it is not a magical solution to every problem. Java will not, for instance, analyze a encryption routine for you and determine if it's cryptographically secure.
Similarly, I would claim that interpreted systems -- such as Sun's JVM, the Python VM, the Perl interpreter and so on -- are not ideal for all applications, because an interpreted system is inefficient. Indeed, some of the inefficiency is caused by the same 'guard against security' which the first poster so lauded.
So, the original poster's apparent point was: Java and C# catch all your errors for you and solve all security problems, everyone should just use those.
My point in reply was: interpreted systems can do runtime error-checking for you in an effective way, but there are downsides.
Hopefully that makes the point I was originally trying to get across clearer, without muddying it in terminology.
(And for the record...if you want to nitpick that javac's a compiler that just happens to target a bytecode, I'm going to assume you only want to argue terminology rather than my actual, original point, and will not play. Yes, javac is a compiler that targets a bytecode. The bytecode is then interpreted by a VM, so I call the javac/JVM combination an interpreted system, dammit.)
Very true, but the most common implementations of the Java, C#, Python, etc. languages are interpreted. Your average Java developer is, at least in my experience, not using GCJ.
:)
Perhaps I misunderstood the original post which I was replying to, but the poster seemed to be making the point that Java and C# -- being interpreted -- fixed all security problems. I concede that an interpreted language fixes some problems because the nature of interpreted code makes it possible to catch some things at runtime (a benefit you lose to some extent when you use tools like GCJ), but I dispute that it fixes all security holes, or that Java and C# are suitable languages for all situations.
I stand by my statement that I would not want to write a low level VXD device driver in Java. (I'd prefer not to write one in C, either, but that's due to a general dislike of the Windows driver system, and neither here nor there.)
It's more than just speed issues. Interpreted languages have better runtime checking and thus can avoid things like buffer overruns, yes. That's great for a lot of things, don't get me wrong. For backend programs, Java is an absolutely brilliant language, as it encourages some much better object-oriented design philosophies. Even Objective C handles some runtime checking far better than C or C++, though as it is a set of extensions to C it suffers from the same weaknesses in C code.
:) Last I checked, the original Java Virtual Machine was written in C...after all, you can't run Java bytecode without something to interpret it. Similarly, I bet you most Just-in-Time Java compiler/interpreters are also written in C or C++. Even the programs which take Java code and turn it into a binary executable likely are linking it against a library which was written in C or C++.
:)
/do/ solve some problems which traditional lower-level languages are more vulnerable too -- modern interpreted are not a panacea for all programming ills. They aren't suitable for all types of programming, and even for the ones they are well-suited for, they don't automatically solve all security issues.
;)
But what is the JVM written in? I guarantee you it isn't Java.
Similarly, at my old job, I had to write low-level drivers for PCI hardware we were developing. Did I get to write these drivers in Java or C#? Of course not... you can't write low-level hardware calls such as Windows VXD files in an interpreted language; it'd really kill the performance of a system.
Just for a moment try to imagine someone writing, say, a new video driver for the Linux kernel in Python, or rewriting XFree86 in Java.
Ow.
Moreover, while Java makes it a great deal harder to, say, create a remote root exploit through a buffer overrun, it does not automatically fix problems of, say, cryptographic strength. Creating an encryption algorithm for some vital data which can be easily broken is as much a security hole and a flaw as a buffer overrun.
So while you're correct in some places -- Java and Python and C# and other interpreted languages that can do more stringent runtime checking of things really
In general, the lower-level the language, the more easily you can mess it up; ASM is even easier to fry things in than C or C++. It becomes a tradeoff, with the lower-level languages giving you progressively greater efficiency and the ability to access things 'down on the metal', with higher level languages -- while slower and more abstracted -- able to shield you from more mistakes, and more portable between situations.
Each has their place. I wouldn't want to write a web-client that ran database queries in ASM, but Java works great. Conversely, I wouldn't want to write a driver for an AGP graphics card in Python, but ASM or C works pretty well right there.
Actually, to be fair, Grave of the Fireflies is one of the very few 'non-standard' anime that people /are/ more likely to have heard of; it's been pushed through enough art-house circuits that it's at least slightly more likely to be known.
That does not, however, negate the general point you made; to build on the terminology in the post I made earlier in this thread, an overabundance of chaff in a genre does turn people off from it as it burns them on out looking for the wheat buried among it.
With 8 million 'panty-shot' anime or recycled-plot series coming out, films like Whisper of the Heart are sadly likely to be overlooked. Heck, even the really beautiful and engrossing Twelve Kingdoms, despite getting translated, is likely going to not get a great deal of notice.
The same is true with books, as well; I'm reading an excellent book by a relative newcomer author, Sarah Ash, but I'll bet you that many people -- having been burned by bad books by newcomers to the fantasy genre -- will skip this one and stick to the authors they already know and like. And that's a shame, because -- while I only just picked up the book, and am only a few chapters in -- so far 'Lord of Snow and Shadows' is a surprisingly engrossing and well-written book.
And really, that's what's to be lamented. The push by publishers and distributors to focus on quantity over quality, to the point that until you've read -- or gone looking for reviews -- a book or watched an anime or whatever, you can't tell the chaff from the wheat. Choice is good, but it does burn some people out and make them stick to the authors/series/works/whatever that they know, not risking the chaff.
Not only that, but many genres suffer from dilution. When there's a dozen people writing in a genre or producing for it, it's far easier to separate the wheat from the chaff. I think today, there's more wheat, but there's also more chaff.
/overall/ has increased.
:)
Today when I go to the bookstore and look at the science-fiction section, I see all these new books, half of which are by authors I've never heard of before. Brand-new, first-time writer, or someone who's just not gotten coverage, or whatever. And every book has testimonials on the cover, someone saying the author is 'The most promising new writer to enter the genre since...' or whatever. So really, the only way to know what's good is to read it yourself... and since there's so much out there these days, there's much more chaff to sort through to find the wheat.
I think it's true with anime, too -- the growing popularity over the past few years has made a number of anime pop up which, honestly, aren't all that worthy, to reference the Miyazaki quote. It's true of almost any medium of fiction and expression when the field becomes crowded; it's not necessarily that the number of worthy things has decreased, but that the number of things
That said, it's nice to see M'Oak get some linkage. Maybe it'll spur a few more T&K fans.
No. And hey, if GPL is your determining feature, then more power to you; GAIM's a great package, too. Sean and the others are cool folks. I happen to think the friendly rivalry between the two only makes both products better by driving us to cheerily outdo each other's new additions, and we have both exceptioned our licenses to contribute code to each other before when needed to help out -- for instance, we've given MSN code to GAIM, and they gave us some code for Yahoo.
/is/ wonky in that area at times, and putting an application under LGPL rather than GPL tends to arouse the Wrath of The Masses. We might've been able to get away with Artistic, but then you don't have the FSF legal council to back you up if your code is stolen. :(
:)
There are also legitimate reasons for Trillian's closed status; there are things we couldn't do in GPL, because partners who want custom versions of Trillian have non-GPL'd libraries they want to put in, stuff like that. The GPL license
I happen to like open source and use it for all my own personal projects, but it's not necessarily the be-all and end-all of software development; both open and closed source have their advantages, and both have their place. Both also have their own flaws, their monsters and boogiemen. It was Scott and Kevin's call, and in the end they preferred the closed-source 'monsters' they knew to the open source ones that they didn't.
Hopefully we go beta within single-digit days, if today's alpha build looks good. :)
Ironically, I find Jabber a much more simple/straightforward protocol than SIP/SIMPLE. Especially as Jabber in its present form can be used as a full-featured instant messaging packages, where SIMPLE is not far enough along, and the only SIMPLE implementations therefore rely on proprietary extensions to flesh it out.
/is/ here right now, and easy to implement, and functional today, and despite some of its own rough edges it's always felt a lot simpler to work with than SIMPLE. XML's pretty darn easy to parse. :)
This isn't a troll; I do honestly think SIP and SIMPLE have their place. SIP is way more suited to negotiating multimedia streams than XMPP/Jabber ever will be. SIMPLE strikes me as much better for handling 'conference call' type situations without relying on Jabber's groupchat implementation, as well.
But SIMPLE just ain't here yet...it's a promising base for a lot of things, and the pledge of various instant messaging networks to support it is great...but it's still under construction. Jabber
Honestly, on the day that all the messaging networks get together and agree on a standard, I'm fairly sure my co-workers and I will be dancing with joy. There's an element of cool challenge to hacking apart the AIM protocol, the ICQ protocol and so on. But it's also a monumental headache and time-consuming task, and the only reason to do it is because right now, there /is/ a need for cross-network clients.
:)
On the day that cross-network clients become unnecessary, our job of making a good central communications client becomes a lot easier, because we don't have to spend so much time making sure so many different protocols all work!
Well, to be fair, there are some definite wackinesses in jabberd 1.4.2 when you're running a really high-volume server, like if you ran jabber.org using the free server.
However, most people are not going to be running 100,000 user servers using the free server version. And I've run a test-server for doing the Jabber work with Trillian for several months now, and not blown it up at all.:)
Some Jabber clients have end-to-end encryption, but the standard on that is still a little shaky. It's basically just a PGP signing and encryption method.
;)
Best Jabber client for Windows presently really depends on what you need and want. Jabberstudio.org has a lot of good ones. Psi is an excellent one, RhymBox is a very clean and easy-to-use one, Exodus has a very plain and un-glitzy UI, but tends to support damned near every part of the protocol that pgm can cram into it. In my opinion, Psi's a good choice for folks coming from the Linux realm, RhymBox is a good choice for Windows-only folks, and Exodus is a great tool if you're a Jabber dev who wants to poke and things (and periodically blow up Exodus by sending it malformed XML while testing).
Uh. Worst competition?
:)
No, we just didn't include Jabber earlier because AIM, ICQ, MSN and Yahoo are a bitch to write for, and the time and energy needed to go into getting those right first. It's called prioritization of limited manpower (or, in my case, womanpower).
The Jabber portion's working in the internal alpha builds, and the next version of Trillian does have Jabber support. While I'm not as active in the Jabber dev community at the moment since we're hunkered down debugging and cleaning up to get the next release out, we're pretty devoted to the Jabber community as well. I've been an active participant in standards discussions and revising and authoring JEPs, and we have some long-term plans for Trillian regarding Jabber which are pretty beneficial to both Trillian and Jabber.
No. This 'problem' is not what we've solved with Trillian. The problem we aim to solve with Trillian is 'god, we need a way to have multiple IM and information clients in a single executable, because this is insane.' The problem Jabber aims to solve is 'my god, instant messaging is important to many things, we need an open standard so people can write software and set up servers as they need, without being hooked into proprietary stuff.'
:)
I'm one of the Trillian developers; trust me on this.
Jabber picks up multiple network support on server-side as a benefit of the modular design of the server and extensible nature of the protocol. HOWEVER. The Jabber development community will tell you that the transports are not intended as an all-in-one solution; they're just there to ease the transition to Jabber, so you don't have to lose touch with existing contacts while you're urging them over to Jabber as well. The transports are, in fact, the bane of many a Jabber dev who finds people think of Jabber as a Trillian equivalent -- i.e., looking at it as a way to get onto the legacy networks and not looking at the Jabber protocol and Jabber contacts themselves.
And yes, as noted, Trillian gets Jabber in our next release.
IRC servers can only connect between specific servers -- think of it like a tree. If you knock off a 'hub' server -- a branch -- then all the leaves off that hub are gone.
Jabber, however, is more like e-mail. Any Jabber server can talk to any other Jabber server. Which, yes, like with e-mail means one specific Jabber server might be down, but like e-mail, it means the entire network doesn't fold.
Then again, most of the Slashdot audience may admittedly not be quite as inclined to appreciate things such as Colin Firth in leather pants as those of my gender are. (Mmmm. Hot British guy...)
And 'Whisper' is one of my favorite Ghibli films too, yes. Miyazaki and Kondou had not worked together as a duo since they were younger, and it's a shame they didn't do more together.
Miyazaki also worked on Whisper, but Kondou was the director. It was fulfilling a promise they made each other when they were much younger to make a film like that; it was a film they'd both wanted to make for a very, very long time.
Miyazaki's eulogy for his friend is very touching; it can be found linked from the Kondou page on Nausicaa.net...
...though bear with slow response, as Nausicaa.net is already pretty well experiencing the Slashdot effect. My traffic-shaping rules are helping the site hold its own, but you may have to tolerate sluggish reply at the moment. :)
--Rachel (Nausicaa.net sysadmin)
Whisper of the Heart was directed by Yoshifumi Kondou, who was considered by many to be Miyazaki's protege and eventual successor. After Kondou's amazing work on his directorial debut (Whisper), Miyazaki planned to retire and turn over the helm to Kondou.
Tragically, Kondou died in January 1998 of an aneurysm, never having a chance to direct a second film.
http://www.nausicaa.net/miyazaki/kondo/
The great cop out for open source programmers is the position that they don't want lots of people installing and using their software. If you didn't want people to use it, why did you publicly release it?
/lots/ of people installing and using their software.
:)
Generally? Because you thought it might be useful. The key is, as you pointed out, they may not expect
I've been in the position of creating a package that was useful to me, tossing it out there and figuring one or two other folks might use it...and then discovering 'dear god in heaven, I'm getting 200 support e-mails about this thing a day! Aaaugh!' and starting to pull my hair out. In a way, it's flattering because 'gosh, it was useful' but in a way it's a bit overwhelming if, say, you only have one or two people writing a package and suddenly you have a flood of support requests.