If you want to hate it because it's Microsoft-designed tech, it's fine. But at least be consistent.
This probably summarizes the main concern.
"Never truth Microsoft". Not much else needs to be said about this.
You can deal with microsoft stuff if you thoroughly wash your hands after it. Samba is such a "realpolitik" project. But Mono, at times, seems like settling down at the Redmond sewers.
Linux no longer needs to "desperately" co-operate with Microsoft - internet & web apps rewrote the game. This was not the case when Mono was conceived. Also, back in the day there was not much happening in the cross-platform landscape, whereas now everything is cross-platform (and Mono+Gtk# is an also-ran there).
What do people use Tomboy for anyway? The only thing I've used it for is holding a URL when I rebooted (long story.)
I use it take notes all the time - paste call stacks, breakpoint locations, bug reports, irc discussions.
It doesn't do much (by design!), but it has a well designed ui that doesn't get in the way. I really recommend incorporating it or gnote to your workflow.
"many other KDE4 progs" are meant to be improvements of the originals, it says so right in the version number. I can't see any valid reasons to accept the state a lot of those major releases are in.
Version numbers are hardly a reliable indicator of quality when all/most of the code has changed behind the scenes.
Instead of all the vitriol, route around the problem. Use the Gnome/desktop agnostic counterparts of the programs until the devs fix their packages.
Also, this issue w/ KDE4 has been hashed out over and over again. New code gets written, bugs appear, bugs get fixed, world keeps turning, good time shall be had by all.
Other than that... Nothing can match Visual Studio. Period.
It's not necessary to match Visual Studio. It's important to be good enough. Many programmers are still relying on non-IDEs, so VS level operation is far from necessary.
I don't recall having an open source linux-compatible version of Visual Studio.
Re:Will we get another "don't use me yet" "release
on
KDevelop4 Beta 3 Released
·
· Score: 3, Informative
Seriously, someone needs to find who wrote the fucking memo that says you can have all the regressions you want as long as your applications use Qt4.
It's a new app, there is no such thing as a regression. Same applies to many other KDE4 progs.
That being said, C++ intelligence for KDevelop4 rocks. Too bad it's not as stable as Qt Creator yet (so I already sort of jumped the ship).
For kdevelop4, perhaps they could consider the approach taken by emacs for gdb integration as "competitive" measure- i.e. just act as all-singing, all dancing code showing frontend for gdb, with normal gdb console visible at all times. For many scenarios, dumbened frontends just can't hack it.
What is your point ? did you believe that a C++ programmer would be shy to drop down to assembly when needed ? because they do. Ton of multimedia lib such as codecs are written with assembly bits. Like the fastest software-only H264 decoder.
C++ programmers do not believe in the silver bullet. Dumb shits like Rubyists do.
From the article:
On the plus side, both versions of Python can claim many of the smallest programs in the collection. Ruby (8, 1) might also compete for titles, but unfortunately its performance is so bad its star falls off the performance chart.
Now, I understand the kinship ruby community feels with smalltalk... Squeak performance sucks too, albeit not as badly as ruby.
Why not just use Qt instead? It's LGPL....why people still using GTK?
Because MOC sucks ass.
The *one* extra level in stack frames you'll see from metaobjects is peanuts compared to the horrors of all the boilerplate crap you have write out in your source code to support the hackjob OOP we call GObject.
But the fact is that if you use it on a GTK desktop, people will notice, and such is life that GTK is the de facto standard.
Qt apps actually look like gtk apps on Ubuntu Jaunty (Qt 4.5). This is a relatively new development, so you are forgiven for making the false assumption here;-).
Because for large projects, porting from C to C++ can be non-trivial?
What's the nontrivial part about that? You can switch to g++ from gcc quite easily, and the errors emitted by the more strict compiler can be fixed by any junior developer (some casts, basically).
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
Qt actually runs the glib event loop these days. You can easily verify this by kill -ABRT'ing a kde app and checking the core dump; this just in from kate:
#8 0xb5df874b in IA__g_poll (fds=0x9c225c8, nfds=6, timeout=25243) at/build/buildd/glib2.0-2.20.1/glib/gpoll.c:127 #9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at/build/buildd/glib2.0-2.20.1/glib/gmain.c:2761 #10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at/build/buildd/glib2.0-2.20.1/glib/gmain.c:2511 #11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323
Hey, all of you sitting above my post. Yes, all of you who replied to that moron! Thanks for wasting all that screen real estate so you can feel smart explaining to the layman something he could have JustFuckingGoogled!
Indeed. Seeing explanations for trivial driver like this is even more annoying than people asking about it. Please at least *attempt* to keep slashdot as "news for nerds"...
If you are thinking of GObject, I fail to be convinced. GObject makes you want to *avoid* OOP as much as possible, since it serves as an obfuscation layer - luckily a lot of glib doesn't force you to use it.
C++ compilers cost exactly as much as C compilers these days ($0), so I wouldn't mind if it was relegated to the role where it belongs (which is not full application development).
Flame away, I just migrated back to Vista, and I'm happy now. At least I will be, when I finally set up Eclipse with MinGW.
Sounds like a rather unlikely form of happiness.
P.S. The X log told me direct rendering is not supported with the intel driver. After hours of frustration, and seeing Vista doing just fine, taking about 3 mouse clicks.
Yeah, Intel drivers are fscked in Jaunty. I guess it's a punishment of sorts for people who buy laptops (no "power user" will buy a desktop with intel chip, right?).
I've heard and read that mantra ten years ago. The future is not web-based because no large corporation will put/send/store their sensitive stuff (as in trade secrets) on any other corporation's web servers. Not even email. Ever.
For that, there is this wild thing called intranet.
Where does Hg succeed over Git? My understanding is that a lot of people really don't like the way git merges..
- It gets by with far smaller amount of commands, that are generally understandable and do "what you would expect" (whereas with git, to get "what you would expect" you need to do some serious study).
- It reports failures in a terminology that a normal person can be expected to understand.
- It's implemented in Python and little C for speed, not a hodgepodge of every language known to man.
- Probably deriving from previous point, it has a first-class windows implementation
- It gives revisions in local repo a running index number. It's transient, but often handier than using hashes all the time.
That being said, ease is the single most important benefit. This is important if the repo is being used by people from different backgrounds. Weigh the amount of hand holding you'll need to do for people new to the tool, and it becomes surprisingly important.
GTK+ is not horrible. The reasons people most often cite for it being horrible are in two categories:
The code is so convoluted. That is because it is C and not C++ so it cannot take advantage of features of the language. There are times C (say you want to use it in a C program and do not want to do a bunch of glue code with C linkage) is nice and also it depends on less with a smaller overhead.
Is there a research somewhere that measures overhead / binary size / performance of Gtk+ and Qt programs against each other? I have anecdotal evidence that at least when you are comparing KDE and Gnome programs, the Gnome programs are always the slower ones. Take kate, gedit and 20 meg file, for example.
Gtk+ does OO explicitly with GObject. It sucks to develop for, but I'd wager to guess that it's slower than well-compiled C++ as well (because of frequent type checking).
C is still a good language for, say, making fast modules for scripting languages (integrating C to them is always easier because it has no name mangling), but writing desktop applications is not really where it should be used in the future.
Microsoft probably had a few good laughs looking at the open source community doing their little things with their ancient tools, but that time is over now.
Ideally, GTK+ will be rewritten in Vala. That way, we get C compatibility together with being able to write code in a modern, high-level, C#-like language (with type inference, memory management and anonymous functions, to name a few features).
Yeah, then we'd have a desktop based entirely on language/precompiler that exists solely for the developers of that desktop.
Why not start shipping Gnome as a Smalltalk system image while we are at it?
that's the add-in. I didn't know that existed before. Anyway, the commercial version says it has full visual studio integration. What does that mean? What is the difference. If there is no difference then why would anyone pay the a commercial license?
I don't know what's the status with visual studio toolchain proper at the moment (I don't do windows development); but I think the important thing is the VS compiler + debugger support in qt creator. Full Visual Studio integration (VS IDE) was important before qt creator, since all we had on windows side was the buggy eclipse plugin.
Last I checked QT 4.5 Visual Studio compiler still required a license and lots of money. Only the MinGW + QT was free. I guess it's ok if you use sharedevelop and tell it to use the MinGW compiler toolchain, but for someone wanting the VS integration it is not too good. Has this changed?
have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.
However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.
It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.
Slashdot Mirror
OK, so we have a widget toolkit on top of a Clutter scene graph on top of OpenGL. Is there a reason for the extra layers?
Yes, it's the same reason we don't write our programs in machine code.
Ok, enlighten me - is it like Sidekick from Borland a long, long time ago.
Pretty much. OTOH, I never had much use for Sidekick back then because I was a kid that didn't do anything important enough to jot down ;-).
If you want to hate it because it's Microsoft-designed tech, it's fine. But at least be consistent.
This probably summarizes the main concern.
"Never truth Microsoft". Not much else needs to be said about this.
You can deal with microsoft stuff if you thoroughly wash your hands after it. Samba is such a "realpolitik" project. But Mono, at times, seems like settling down at the Redmond sewers.
Linux no longer needs to "desperately" co-operate with Microsoft - internet & web apps rewrote the game. This was not the case when Mono was conceived. Also, back in the day there was not much happening in the cross-platform landscape, whereas now everything is cross-platform (and Mono+Gtk# is an also-ran there).
What do people use Tomboy for anyway? The only thing I've used it for is holding a URL when I rebooted (long story.)
I use it take notes all the time - paste call stacks, breakpoint locations, bug reports, irc discussions.
It doesn't do much (by design!), but it has a well designed ui that doesn't get in the way. I really recommend incorporating it or gnote to your workflow.
KDE4 already has C# bindings.
It's a matter of time before some "revisionist" starts using them.
There are C# bindings for Qt, but I doubt they are of interest to many - mostly because "native" Qt coding doesn't suck.
"many other KDE4 progs" are meant to be improvements of the originals, it says so right in the version number. I can't see any valid reasons to accept the state a lot of those major releases are in.
Version numbers are hardly a reliable indicator of quality when all/most of the code has changed behind the scenes.
Instead of all the vitriol, route around the problem. Use the Gnome/desktop agnostic counterparts of the programs until the devs fix their packages.
Also, this issue w/ KDE4 has been hashed out over and over again. New code gets written, bugs appear, bugs get fixed, world keeps turning, good time shall be had by all.
Other than that... Nothing can match Visual Studio. Period.
It's not necessary to match Visual Studio. It's important to be good enough. Many programmers are still relying on non-IDEs, so VS level operation is far from necessary.
I don't recall having an open source linux-compatible version of Visual Studio.
Seriously, someone needs to find who wrote the fucking memo that says you can have all the regressions you want as long as your applications use Qt4.
It's a new app, there is no such thing as a regression. Same applies to many other KDE4 progs.
That being said, C++ intelligence for KDevelop4 rocks. Too bad it's not as stable as Qt Creator yet (so I already sort of jumped the ship).
For kdevelop4, perhaps they could consider the approach taken by emacs for gdb integration as "competitive" measure- i.e. just act as all-singing, all dancing code showing frontend for gdb, with normal gdb console visible at all times. For many scenarios, dumbened frontends just can't hack it.
What is your point ? did you believe that a C++ programmer would be shy to drop down to assembly when needed ? because they do.
Ton of multimedia lib such as codecs are written with assembly bits. Like the fastest software-only H264 decoder.
C++ programmers do not believe in the silver bullet. Dumb shits like Rubyists do.
From the article:
On the plus side, both versions of Python can claim many of the smallest programs in the collection. Ruby (8, 1) might also compete for titles, but unfortunately its performance is so bad its star falls off the performance chart.
Now, I understand the kinship ruby community feels with smalltalk... Squeak performance sucks too, albeit not as badly as ruby.
Why not just use Qt instead? It's LGPL....why people still using GTK?
Because MOC sucks ass.
The *one* extra level in stack frames you'll see from metaobjects is peanuts compared to the horrors of all the boilerplate crap you have write out in your source code to support the hackjob OOP we call GObject.
But the fact is that if you use it on a GTK desktop, people will notice, and such is life that GTK is the de facto standard.
Qt apps actually look like gtk apps on Ubuntu Jaunty (Qt 4.5). This is a relatively new development, so you are forgiven for making the false assumption here ;-).
Because for large projects, porting from C to C++ can be non-trivial?
What's the nontrivial part about that? You can switch to g++ from gcc quite easily, and the errors emitted by the more strict compiler can be fixed by any junior developer (some casts, basically).
No his problem is that QT has an execution loop which incompatible with the Chrome engine. What makes QT so cool for event driven programming is an event handler that can't be easily changed to match the event handler in Chrome.
Qt actually runs the glib event loop these days. You can easily verify this by kill -ABRT'ing a kde app and checking the core dump; this just in from kate:
#8 0xb5df874b in IA__g_poll (fds=0x9c225c8, nfds=6, timeout=25243) at /build/buildd/glib2.0-2.20.1/glib/gpoll.c:127 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2761 /build/buildd/glib2.0-2.20.1/glib/gmain.c:2511
#9 0xb5deaf82 in g_main_context_iterate (context=0x9778e90, block=1, dispatch=1, self=0x9776f40) at
#10 0xb5deb268 in IA__g_main_context_iteration (context=0x9778e90, may_block=1) at
#11 0xb6a5f438 in QEventDispatcherGlib::processEvents (this=0x9763c68, flags={i = -1074473992}) at kernel/qeventdispatcher_glib.cpp:323
Hey, all of you sitting above my post. Yes, all of you who replied to that moron! Thanks for wasting all that screen real estate so you can feel smart explaining to the layman something he could have JustFuckingGoogled!
Indeed. Seeing explanations for trivial driver like this is even more annoying than people asking about it. Please at least *attempt* to keep slashdot as "news for nerds"...
You wouldn't say that if you saw C done properly.
If you are thinking of GObject, I fail to be convinced. GObject makes you want to *avoid* OOP as much as possible, since it serves as an obfuscation layer - luckily a lot of glib doesn't force you to use it.
C++ compilers cost exactly as much as C compilers these days ($0), so I wouldn't mind if it was relegated to the role where it belongs (which is not full application development).
Flame away, I just migrated back to Vista, and I'm happy now. At least I will be, when I finally set up Eclipse with MinGW.
Sounds like a rather unlikely form of happiness.
P.S. The X log told me direct rendering is not supported with the intel driver. After hours of frustration, and seeing Vista doing just fine, taking about 3 mouse clicks.
Yeah, Intel drivers are fscked in Jaunty. I guess it's a punishment of sorts for people who buy laptops (no "power user" will buy a desktop with intel chip, right?).
I remember that I actually had *one* game that supported my Virge/DX - Descent 2.
It did look a better, but was slow enough to make you want to switch to software rendering immediately.
The name "Diamond Multimedia Stealth 3D 2000 PRO" did sound rather impressive on paper.
The article would have been more impressive with screenshots of the games, though.
I've heard and read that mantra ten years ago. The future is not web-based because no large corporation will put/send/store their sensitive stuff (as in trade secrets) on any other corporation's web servers. Not even email. Ever.
For that, there is this wild thing called intranet.
Where does Hg succeed over Git? My understanding is that a lot of people really don't like the way git merges..
- It gets by with far smaller amount of commands, that are generally understandable and do "what you would expect" (whereas with git, to get "what you would expect" you need to do some serious study).
- It reports failures in a terminology that a normal person can be expected to understand.
- It's implemented in Python and little C for speed, not a hodgepodge of every language known to man.
- Probably deriving from previous point, it has a first-class windows implementation
- It gives revisions in local repo a running index number. It's transient, but often handier than using hashes all the time.
That being said, ease is the single most important benefit. This is important if the repo is being used by people from different backgrounds. Weigh the amount of hand holding you'll need to do for people new to the tool, and it becomes surprisingly important.
GTK+ is not horrible. The reasons people most often cite for it being horrible are in two categories:
The code is so convoluted.
That is because it is C and not C++ so it cannot take advantage of features of the language. There are times C (say you want to use it in a C program and do not want to do a bunch of glue code with C linkage) is nice and also it depends on less with a smaller overhead.
Is there a research somewhere that measures overhead / binary size / performance of Gtk+ and Qt programs against each other? I have anecdotal evidence that at least when you are comparing KDE and Gnome programs, the Gnome programs are always the slower ones. Take kate, gedit and 20 meg file, for example.
Gtk+ does OO explicitly with GObject. It sucks to develop for, but I'd wager to guess that it's slower than well-compiled C++ as well (because of frequent type checking).
C is still a good language for, say, making fast modules for scripting languages (integrating C to them is always easier because it has no name mangling), but writing desktop applications is not really where it should be used in the future.
Microsoft probably had a few good laughs looking at the open source community doing their little things with their ancient tools, but that time is over now.
Ideally, GTK+ will be rewritten in Vala. That way, we get C compatibility together with being able to write code in a modern, high-level, C#-like language (with type inference, memory management and anonymous functions, to name a few features).
Yeah, then we'd have a desktop based entirely on language/precompiler that exists solely for the developers of that desktop.
Why not start shipping Gnome as a Smalltalk system image while we are at it?
that's the add-in. I didn't know that existed before. Anyway, the commercial version says it has full visual studio integration. What does that mean? What is the difference. If there is no difference then why would anyone pay the a commercial license?
I don't know what's the status with visual studio toolchain proper at the moment (I don't do windows development); but I think the important thing is the VS compiler + debugger support in qt creator. Full Visual Studio integration (VS IDE) was important before qt creator, since all we had on windows side was the buggy eclipse plugin.
Just try Qt Creator.
Is there any kind of Mercurial hosting for open source projects you can recommend?
http://bitbucket.org/
And soon, google code
Last I checked QT 4.5 Visual Studio compiler still required a license and lots of money. Only the MinGW + QT was free. I guess it's ok if you use sharedevelop and tell it to use the MinGW compiler toolchain, but for someone wanting the VS integration it is not too good. Has this changed?
http://www.qtsoftware.com/downloads/visual-studio-add-in
have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.
However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.
It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.