But if you don't write your own widgets, much of the object orientation mess is hidden. Or rather, it's there in plain sight but you don't have to worry much about it.
And if you happen to be a fan of C++, just use the gtkmm libraries and get a "proper" C++ class hierarchy. If you like Java, use Java-GNOME and I would suppose that the Python bindings also use the languages native object orientation.
As a commercial software developer as well as open source developer, I prefer licenses that allow me to use both. I often integrate open source code with BSD style licenses in the commercial projects, and I contribute open source code to the community. It's a give and take thing.
Qt does not give me freedom. It uses the GPL to take it away.
And I know exactly what you're going to say now. I develop commercial applications, I should pay for it, blah blah. Windows doesn't force me to do this. Neither does OSX. Not even (formerly) commercial toolkits such as Motif used to do this.
If a commercial software developer wants to use Qt and pay for it. Fine, I'm sure he'll be very happy. But I think it's wrong to force this policy onto all users of the system. It means that commercial developers can create a Windows and an OSX version without paying for the library, but not a Linux version. Do you seriously think that is a good thing when you are trying to take over the desktop from Windows?
No your don't. If you want to do closed-course development with Qt you have to pay a one-time fee. Get your facts straight - GPL != non-commercial. Ask Redhat.
Amazing how many people doesn't read the licenses.
I'm not only referring to you, but all the other people posting in this thread.
Thing is, you can't even do all kinds of open source development with a GPL'ed library. You need to use the GPL license yourself. No others are acceptible.
The kind of tough commercial licensing Qt has is even worse than that of Windows. Sorry, I just don't like it.
Now please mark me offtopic. I deserve it. This really has nothing to do with the article.
Furthermore, if you add up those sales and do the sums, the mean average price paid by the current Magnatune audience for an album is $8.35. While it's encouraging that that's $0.35 above the default price, what's not encouraging is that it's not much above it - surely the cost of implementing such a service and the potential drawbacks (ie, almost everyone paying the minimum or nobody paying above the default) make this a less than attractive option to even a liberal music exec.
What we don't know is what the total sales would be of they fixed the price point at 8 USD. What if they fixed it at 8.35 USD? Do you honestly think that they would earn as much?
X isn't and never was bloated. People think it's large just because the framebuffer memory is included in the "ps" listing.
Read the explanation on the freedesktop site. There they mention the fact that people developed X on really old VAX machines. I even ran X myself on an old VAXStation II which had several times less memory than your average palmtop computer, hardware which happens to run X as well.
It's the dual meaning that makes the name so great. And the fact that they don't mention it in the description makes us who understand it feel so much better about it.:-)
Yes they do. Pretty much everything is (should be) inverted. The next time you write a GUI application, make sure you consider this. The toolkits has various features that help with this.
When looking at screenshots of the arabic GNOME desktop is appears that the user interfaces aren't inverted the way they should be. That can probably be attributed to mistakes by the programmer though.
Sounds simple doesn't it? It's not quite accurate though.
You are probably referring to the fact that a userland application can't mess with the OS installation. However, I could easily write an application that mimics Gator eWallet that would run in GNOME and Mozilla/Galeon/Epiphany.
The only reason these things doesn't exist (or at least very rare) for Linux is that there aren't enough clueless users yet. If they switch from Windows you can be sure that the spyware will follow.
Linux does make it a lot easier to identify spyware though. Fewer places to look, and contrary to windows you can always trace what is happening.
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
You raise a number of good points, but unformatunately I am unable to give any insightful response to the core of your argument:
And Python, as an example, does not suffer from this. It offers an easy path.
I don't know Python. I have quickly browsed some tutorals, which is enough to understand something about the language. Personally I just couldn't stand the syntax (the same reason I turned my back on Ruby too).
I would assume that you learned Java before learning Python? If this is the case, then you overcame most of the object orientation hurdles learning Java, which might very well be a reason you groked Python so quickly. Or maybe not.:-)
My current feeling for Java is that it's expanding and morphing faster than any human mind that doesn't do anything but try to keep track of it can reasonably cope with.
This is one of the reasons like Java.:-) There is just so much stuff out there that you never really have to build anything from scratch. Just like CPAN for Perl, just larger in scope (CPAN doesn't have many enterprise application frameworks of the J2EE kind).
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
An experienced programmer can pick up Python in a matter of minutes. I have not found this to be true of Java.
This may be true. I have never taught Python nor SMalltalk to anyone. In fact, I can't say I know any of the languages.
I have, however, observed over the years that the biggest hurdle for people to overcome when learning Java is to understand how to write object oriented code, and use it to your advantage.
How long did it take for you to learn Java?
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 2, Insightful
In the EJB case, I agree that they are very complex. I've been developing EJB-based applications for several years now and one of the biggest problems for me is to explain the concept for newcomers, even if these newcomers are very good Java developers.
Unix is complex too. I'm not talking about using the shell or the GNOME desktop. I'm referring to learning how to develop a good application. Learning C well, and learning all the Unix system calls, what they do, proper error handling, and making sure that your application not only works on your specific Linux system but also on all other Unices that are out there. As it happens, these are the exact same problems that EJB developers struggle with.
With Windows (.NET components) there are much fewer problems since there is only one implementation and one company producing this implementation (and please don't mention Mono, they are playing the catchup game and Microsoft will never do anything that makes life easier for them or their developers, unless it also makes it easier for themselves).
With regards to Java in general I can't agree with you. Java is extremely easy to get into, and the only thing that can be difficult for C (and in many respects C++) programmers is to learn proper object oriented methologies. With some experience with other object oriented languages like Smalltalk or Python, learning Java is a matter of hours.
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
There used to be somehting called "green threads" for Java where all Java threads were handled by a single OS thread. These trheads were not pre-emptive.
What you are thinking about is most likely the "many to many" thread model in which a POSIX thread is not necesarily mapped to a real kernel thread (or LWP (light-weight process) as it's sometimes referred to). This model used to be the default in Solaris up to version 7, but it later changed to the "one to one" model where each POSIX thread is always handled by its own kernel thread. In Solaris, this proved to give better performance in almost all cases.
Linux has, to my knowledge, always used a "one to one" model, which means that every Java thread lives in its own kernel thread. This can easily be confirmed by started a number of Java threads and compare that to the number of kernel threads that has been created.
And if you happen to be a fan of C++, just use the gtkmm libraries and get a "proper" C++ class hierarchy. If you like Java, use Java-GNOME and I would suppose that the Python bindings also use the languages native object orientation.
As a commercial software developer as well as open source developer, I prefer licenses that allow me to use both. I often integrate open source code with BSD style licenses in the commercial projects, and I contribute open source code to the community. It's a give and take thing.
Qt does not give me freedom. It uses the GPL to take it away.
And I know exactly what you're going to say now. I develop commercial applications, I should pay for it, blah blah. Windows doesn't force me to do this. Neither does OSX. Not even (formerly) commercial toolkits such as Motif used to do this.
If a commercial software developer wants to use Qt and pay for it. Fine, I'm sure he'll be very happy. But I think it's wrong to force this policy onto all users of the system. It means that commercial developers can create a Windows and an OSX version without paying for the library, but not a Linux version. Do you seriously think that is a good thing when you are trying to take over the desktop from Windows?
I'm not only referring to you, but all the other people posting in this thread.
Thing is, you can't even do all kinds of open source development with a GPL'ed library. You need to use the GPL license yourself. No others are acceptible.
The kind of tough commercial licensing Qt has is even worse than that of Windows. Sorry, I just don't like it.
Now please mark me offtopic. I deserve it. This really has nothing to do with the article.
In fact, when coupled with this joystick you can actually program the pedals to mimic both keyboard and mouse movements.
Who needs a keyboard? :-)
And yes... I do have that setup myself. Yes I am a sorry person.
Repeat after me: "OpenLook is not X".
That said, Sun still has their X server installed in /usr/openwin. At least they did back in Solaris 8. :-)
For games I agree it could be cool though. :-)
Cyclic = two axes, Collective, and Rudder.
Read the explanation on the freedesktop site. There they mention the fact that people developed X on really old VAX machines. I even ran X myself on an old VAXStation II which had several times less memory than your average palmtop computer, hardware which happens to run X as well.
It's the dual meaning that makes the name so great. And the fact that they don't mention it in the description makes us who understand it feel so much better about it. :-)
When looking at screenshots of the arabic GNOME desktop is appears that the user interfaces aren't inverted the way they should be. That can probably be attributed to mistakes by the programmer though.
I'd say he's at least as good as Purple Motion.
Not in sweden. In eastern europe they do however, AFAIK.
I honestly hope that no one is using ANSI character encodings anymore. I believed that the last renamnts went out with DOS?
Solaris already has GNOME. Just don't run 5-year old versons.
Hint: ascii is 7-bit.
You are probably referring to the fact that a userland application can't mess with the OS installation. However, I could easily write an application that mimics Gator eWallet that would run in GNOME and Mozilla/Galeon/Epiphany.
The only reason these things doesn't exist (or at least very rare) for Linux is that there aren't enough clueless users yet. If they switch from Windows you can be sure that the spyware will follow.
Linux does make it a lot easier to identify spyware though. Fewer places to look, and contrary to windows you can always trace what is happening.
Damn it, reading on I realised that this message, while still funny, has been posted before. Still would like to see it modded to -1 funny.
Really, this is a candidate for +5 funny. Unfortunately, too many people seems to be humour inhibited.
And you are here because?
I would assume that you learned Java before learning Python? If this is the case, then you overcame most of the object orientation hurdles learning Java, which might very well be a reason you groked Python so quickly. Or maybe not. :-)
This is one of the reasons like Java.I have, however, observed over the years that the biggest hurdle for people to overcome when learning Java is to understand how to write object oriented code, and use it to your advantage.
How long did it take for you to learn Java?
Unix is complex too. I'm not talking about using the shell or the GNOME desktop. I'm referring to learning how to develop a good application. Learning C well, and learning all the Unix system calls, what they do, proper error handling, and making sure that your application not only works on your specific Linux system but also on all other Unices that are out there. As it happens, these are the exact same problems that EJB developers struggle with.
With Windows (.NET components) there are much fewer problems since there is only one implementation and one company producing this implementation (and please don't mention Mono, they are playing the catchup game and Microsoft will never do anything that makes life easier for them or their developers, unless it also makes it easier for themselves).
With regards to Java in general I can't agree with you. Java is extremely easy to get into, and the only thing that can be difficult for C (and in many respects C++) programmers is to learn proper object oriented methologies. With some experience with other object oriented languages like Smalltalk or Python, learning Java is a matter of hours.
To each their own I suppose.
There used to be somehting called "green threads" for Java where all Java threads were handled by a single OS thread. These trheads were not pre-emptive.
What you are thinking about is most likely the "many to many" thread model in which a POSIX thread is not necesarily mapped to a real kernel thread (or LWP (light-weight process) as it's sometimes referred to). This model used to be the default in Solaris up to version 7, but it later changed to the "one to one" model where each POSIX thread is always handled by its own kernel thread. In Solaris, this proved to give better performance in almost all cases.
Linux has, to my knowledge, always used a "one to one" model, which means that every Java thread lives in its own kernel thread. This can easily be confirmed by started a number of Java threads and compare that to the number of kernel threads that has been created.
I hope this answers your question.