> Solution: stop checking in stuff that doesn't work.
You never worked on a feature that took more than a day to finish? Maybe even a week or more? If you work with a SCM that doesn't allow local commits and people don't commit their work at least twice a day something goes wrong. I've seen companies where people worked for weeks or even a month on a local checkout without committing. Which has tons of disavantages: You can't do partial reverts if a part of the solution didn't work out, the work is not backed up in a sensible manner and not available to any co-workers, you don't get changesets from upstream and the conflicts when committing your stuff will kill you (you basically have a branch without SCM support...).
If I can't commit my work at least every hour, I feel uncomfortable.
> I agree that's popular, but I don't think it's a
> good idea. Wouldn't it be better to have every
> check-in be stable?
That impossible for bigger changes or even whole features. Or you work for a very long time on your local checkout without committing. That's even more pain and risk than merging in SVN.
In GIT (or any other distributed VCS), it's easy to do local commits and later push those commits upstream keep the commits separated (In SVN, a complete merge is one big commit, or you need to merge each commit manually).
Usually you have production code, in a stable branch. Branch 1.
Then you have the development version. Branch 2.
As soon as you want to develop something that takes some time to finish and you don't want to break the development version for everyone else working on it. Branch 3.
None of these branches can be reasonably avoided, but you need to merge between them, esp. between 2 and 3 (If the number of branches is 2, it's often as easy to backport bugfixes manually to the production code).
> What we've seen of "Web 2.0" has been crappy. It's built upon > layers of shit like JavaScript and Flash.
What "Web 2.0" site uses flash? youtube does, but just for playing video files, not for other content or navigation. The JS hell is not optimal, but pure XHTML isn't suited either for more dynamic websites where you don't want to reload the complete page all the time just because a new mail arrives (gmail for example).
> Krita is fine but I wish they would do some more work > on the object based graphics program, Karbon
You are welcome to join the team:-) Manpower in FLOSS isn't something you can shift over to another app just because some boss or visionary says that karbon needs more love. Developers usually work on the apps they find useful (either "egocentrical" just for themselves, or for users in general), where they are skilled in, where the codebase is fun to work with, etc.
Interesting, for it's just other way round. I never find what I search for in GIMP, and I never get my simple tasks done in GIMP without much trial and error. Well, I am a casual user and not a graphics guy at all. But I personally miss a graphics program that doesn't need you to be a graphics pro to use it.
With Krita, I was far more productive and quicker for my simple tasks (which is color adjustments for photos, mark something in a screenshot with arrows or rectangles, adding text...).
KDE4 will be available for Windows (the platform and apps, not the window manager and panel). KOffice 2 (based on KDE4) will also be ported to Win then (which is not much effort when the KDE libraries are ported).
> Does it acheive a goal that couldn't have been achived > within the GIMP codebase with less effort?
You assume that the goals of GIMP and Krita a similar enough so that "different UI modes" would satisfy both sides.
Then you assume that - the GIMP devels are cooperative enough to follow suggestions by the Krita team. As the other poster points out, this is apparently not the cae. - the gimp code base is something Krita devels want to work with. The Krita code is highly modular, and e.g. switching color models is simple, while the GIMP is struggling just to increase the internal color depth due to bad modularization.
All that of course doesn't prevent code reuse. E.g. for filter algorithms, Gimp code is probably often a starting point for Krita devels.
That call for unification and not wasting effort by implementing stuff twice often comes from people not developing larger OSS projects at all, and not knowing the code quality of the respective projects. E.g., KOffice and Abiword/Gnumeric devels tried to use OOo's filters for MS formats. Unfortunately OOo's MS filter code is crappy and unmantainable (just for example, with german comments from star division era), and not modular at all. If the code isn't modular enough to be ripped out, or too bad to be mantainable by your team, you are better off doing it on your own. (OTOH, of course one should evaluate existing code first, and not just start a new project because of NIH syndrome)
Maybe you find it boring, but one of the most interesting aspects of life are its beginnings, it's basic building blocks and mechanisms. All this happens on cell level. You don't need more than monads to study it. If we'd find life on mars or elsewhere in the solar system that has common origins with terran life, that would be interesting enough. Finding completely different organisms would be revolutionary and change our worldview forever (I think).
The two big questions regarding life:
1. is there _any_ life out there? And if, how does it work? 2. Are there "intelligent" life forms we can maybe even communicate with?
Question 1 being answered in my lifetime would suffice for me;-)
> Now if the Gnome guys (and KDE guys, too) could just > figure out a way to have decent fonts installed by > default
Well, KDE nor Gnome create or package fonts, so this is up to the distros. The only thing KDE and Gnome can do (or their respective UI toolkits) is ot render the fonts nicely. And even that is mostly business of freetype (who can't implement all the good algorithms due to patents).
> The mouse in its current form is about to be rendered obsolete.
> With XGL, Quartz3D, AeroGlass, and Looking Glass, we are most assuredly moving twoards fully-3d
> computer enviroments.
A bold statement. Do you have any good arguments that suggest such a change? Most HCI and visualization people would disagree. Shneiderman for example, says that 3D is only useful where you have data that is best visualized as 3D. He certainly does not suggest navigation in 3D for everyday tasks.
First, having some useful 3D effects using XGL or AeroGlass doesn't mean that the whole environment becomes three-dimensional. For example, the navigation is still 2D for a good reason.
The screen is 2D, so is text. Why should text-oriented work be done in 3D?
If 3D is really the future, it needs better devices than a 2D screen. And headsets don't cut it, they disconnect you too much from your surroundings.
Just because something works out in Doom, doesn't mean it's a good idea for browsing the web, writing e-mails or accounting. There are niches of course where 3D would make sense. But I don't see a reason why usual office work should become full 3D. Without good arguments pro 3D, I continue to think that it's just a pipedream of some 3D enthusiasts (techies), who don't know much about creating interfaces designed for the actual tasks people have to perform.
It's not that "useful" and "good-looking" are alternative. Good technology is both good-looking and useful. Why must a useful device look ugly? If the designer adheres to "form follows function", it should be possible to have a both useful and elegant device.
Well, you can always strip the HTML away. A regexp killing off everything looking like an HTML tag should do.
The far bigger problem for us aggregator authors is that RSS doesn't specify whether the content is HTML or plain text - one just has to guess. Is this just a bracket or is it a tag? Do I have to resolve entities? RSS 0.94 or something contained a type attribute to specify HTML, but the recent RSS 2.0 spec says "the description MAY contain HTML". May contain, may not contain. How stupid is that?
The Atom format is much better specified - and content type is a central attribute (with plain text as default) of the respective tags such as title, summary, content. Unfortunately Atom is bit late now to make it and break the RSS2 dominance.
> I hate KDE because it uses QT. A tool that enforces your resulting work to be > free doesnot really feel likes a free tool.
You are not forced at all to release your KDE software under GPL. Feel free to purchase a Qt license from Trolltech, and you can release your software under whatever license you want.
> Using javac is the minimum you need to program
> java in any environment. It is in fact all you
> need, unless you want additional tools.
I don't know what the magic is behind javac you want to teach. It's quite simple: javac SomeClass.java; java SomeClass", or similar. You can teach that at the beginning when teaching "Hello World", that is where it fits in. For any bigger project with more than 2 files you better should teach them how to use a build system like ant.
I remember myself in my beginnings (mostly in highschool times) writing handmade compile scripts where a Makefile would have been far more appriopriate (and less time-consuming when compiling).
If you need to teach specific tools at all, do not spend all the time at this basic level. Start with the basics, yes, but don't stop there, go on to higher-level tools, more appriopriate for building large software systems. Otherwise people will try to build skyscrapers by assembling sandcorns manually.
> It's a shame that RSS couldn't still
> be RDF... RDF needs more "killer
> apps".
First of all, RDF needs a better XML representation. In it's current form, RDF/XML is confusing and hardly human- (or: programmer-)readable.
For the average programmer who wants to write a little RSS-processing app and doesn't care about semantic web and the like, RSS2 or Atom are just more clear and less obfuscated. Of course, having 1000 formats and variants is a problem, too. But the basic XML representation of these formats makes simple things simple, RDF does not.
I like the RDF model (somewhat, if Reification wasn't that complicated, I would like it even more), but the XML representation sucks for simple purposes like syndication.
> all books have unique identifiers (ISBNs)
What is this exactly good for? an ISBN is an ID, and that only helps if I have that ID. I actually never have it when I search for a book. I know the author, or some part of the title etc.
> "expert classification" (the Dewey system)
So, from where should I know where Dewey's Classification puts the books in? Some expert may say "This book is about A", but I see other aspects B and C. No static, pre-defined classification scheme can catch all possible categorizations that make sense to users. Tagging could help here. Let's see if it is really useful at amazon.
"Free association" means here that there are no pre-defined categories or even hierarchies of terms, but that the user can assign every keyword.
About the "innovation" in tagging: No, tagging is not rocket science. It's not the new, great, hyper-complex funky concept that solves all our problems. Fortunately not. It's simple, and that's why it's good. People get it, and people use it, and that's why its useful. The social aspect, letting the "masses" do the categorization is what makes it useful.
It's like with most successes on the net: Is HTML rocket science which was never there before? No. There were far more complex hypertext systems which made some researchers rave, but which never took off.
Well, Beagle might be a nice and working implementation (I never used it much and haven't read the code, so I can't tell), but it is not exactly what tenor aims to be.
Tenor's primary goal is not about search, but about linking related desktop resources (a resource can be a file, a website, an email, a post-it note, an abstract idea, a person in your address book). So you get a "web of context" which makes it possible to present the user the information is actually interested in in his current context.
This is beyond what beagle does: collect metadata, build an index, search it via search string. That is not rocket science, and was there on the web for a decade now. Also, it's limited, it can't find the picture my friend sent me via IM yesterday.
Beagle is good because it already works, and tenor is still a concept, but from the idea behind it, Tenor is more compelling IMO. And it's not a Beagle clone by no means.
The folks at OpenUsability supporting OS projects all the time, made several usability reports and gave also useful hints for my project. These reports are not visible on the main site, but you can find them if you browse the project list.
The most visible work of the openusability folks will be the KDE4 HIG and usability work there. The openusability people also support developers on KDE usability MLs, IRC, or just face to face on conferences and such. They do a great job, if you don't see much of it at the openusability main site.
The point is, that RSS brings the news to you and you don't have to go for them. Convenience is the key. It's notification vs. polling (well, it polls in the background, but for you as a user it feels like notification).
If I have a friend who updates his RSS-enabled webpage once in two weeks, I see it in my RSS reader when it happens instead of visiting his page manually once a week or so to just see that nothing has changed.
For slashdot and other high-traffic news sites the benefit isn't that big, but it still makes reading news faster and more convenient, if you use a good RSS reader.
I can follow 50 personal homepages and occasional updates blogs without much effort. Do this without RSS.
The argument "it's just a simple XML file, so where is point" is not a good one, as every good web technology is simple. Did the WWW take over because it was the most sophisticated technical solution? No, it take over because it scales relatively well (compared to things like gopher) and because its simple. I am sure there were many people like you 15 years ago saying "HTML? It's just a simple text file, so where is the point?".
> Not just use someone elses lego bricks to build
> some bloatware system thats has all the
> stability and robustness of a 1 legged stool.
So you say a system built of "your own sandcorns" is more stable than using "someone elses lego bricks"? Lego bricks being available as libraries are mostly better tested (more eyes) than the stuff you coded for your own.
Just look at the security problems with C:
Because most C coders have to play with char arrays for string handling instead of using a string class, we have all these buffer overflows all the time.
Using a string class that abstracts from the nasty details makes the code less error-prone and more secure. A common string class gets more code review than your own privately used code will ever get.
Also, abstractions make the code less complex and thus improve code quality.
> Its a bit like car maintenance
No, its more like building skyscrapers. Nobody would build them out of sandcorns at the building site. You use components.
> This is a good example of the philosophy of flexibility so pervasive in Gentoo's portage
Actually it's a pain in the ass. Apparently it causes a lot of problems, considering the amount of gentoo users that come to the KDE IRC channels, having problems because they haven't got package X installed to get KY working.
> In fact, I wouldn't be surprised if someone has made RPMs or DEBs of individual apps.
Breaking news: Debian has splitted packages for _years_.
Afaik this will be fixed in kdepim 3.4.2. Which compiler version do you use? I've seen this bug once, and it was from a gcc 2.95 user. But I guess you don't use 2.95, right?
Slashdot Mirror
> Solution: stop checking in stuff that doesn't work. You never worked on a feature that took more than a day to finish? Maybe even a week or more? If you work with a SCM that doesn't allow local commits and people don't commit their work at least twice a day something goes wrong. I've seen companies where people worked for weeks or even a month on a local checkout without committing. Which has tons of disavantages: You can't do partial reverts if a part of the solution didn't work out, the work is not backed up in a sensible manner and not available to any co-workers, you don't get changesets from upstream and the conflicts when committing your stuff will kill you (you basically have a branch without SCM support...). If I can't commit my work at least every hour, I feel uncomfortable.
> I agree that's popular, but I don't think it's a > good idea. Wouldn't it be better to have every > check-in be stable? That impossible for bigger changes or even whole features. Or you work for a very long time on your local checkout without committing. That's even more pain and risk than merging in SVN. In GIT (or any other distributed VCS), it's easy to do local commits and later push those commits upstream keep the commits separated (In SVN, a complete merge is one big commit, or you need to merge each commit manually).
Usually you have production code, in a stable branch. Branch 1. Then you have the development version. Branch 2. As soon as you want to develop something that takes some time to finish and you don't want to break the development version for everyone else working on it. Branch 3. None of these branches can be reasonably avoided, but you need to merge between them, esp. between 2 and 3 (If the number of branches is 2, it's often as easy to backport bugfixes manually to the production code).
> What we've seen of "Web 2.0" has been crappy. It's built upon
> layers of shit like JavaScript and Flash.
What "Web 2.0" site uses flash? youtube does, but just for playing video files, not for other content or navigation.
The JS hell is not optimal, but pure XHTML isn't suited either for more dynamic websites where you don't want to reload the complete page all the time just because a new mail arrives (gmail for example).
> Krita is fine but I wish they would do some more work
:-)
> on the object based graphics program, Karbon
You are welcome to join the team
Manpower in FLOSS isn't something you can shift over to another app just because some boss or visionary says that karbon needs more love. Developers usually work on the apps they find useful (either "egocentrical" just for themselves, or for users in general), where they are skilled in, where the codebase is fun to work with, etc.
Interesting, for it's just other way round. I never find what I search for in GIMP, and I never get my simple tasks done in GIMP without much trial and error. Well, I am a casual user and not a graphics guy at all. But I personally miss a graphics program that doesn't need you to be a graphics pro to use it.
With Krita, I was far more productive and quicker for my simple tasks (which is color adjustments for photos, mark something in a screenshot with arrows or rectangles, adding text...).
KDE4 will be available for Windows (the platform and apps, not the window manager and panel). KOffice 2 (based on KDE4) will also be ported to Win then (which is not much effort when the KDE libraries are ported).
> Does it acheive a goal that couldn't have been achived
> within the GIMP codebase with less effort?
You assume that the goals of GIMP and Krita a similar enough so that "different UI modes" would satisfy both sides.
Then you assume that
- the GIMP devels are cooperative enough to follow suggestions by the Krita team. As the other poster points out, this is apparently not the cae.
- the gimp code base is something Krita devels want to work with. The Krita code is highly modular, and e.g. switching color models is simple, while the GIMP is struggling just to increase the internal color depth due to bad modularization.
All that of course doesn't prevent code reuse. E.g. for filter algorithms, Gimp code is probably often a starting point for Krita devels.
That call for unification and not wasting effort by implementing stuff twice often comes from people not developing larger OSS projects at all, and not knowing the code quality of the respective projects. E.g., KOffice and Abiword/Gnumeric devels tried to use OOo's filters for MS formats. Unfortunately OOo's MS filter code is crappy and unmantainable (just for example, with german comments from star division era), and not modular at all.
If the code isn't modular enough to be ripped out, or too bad to be mantainable by your team, you are better off doing it on your own.
(OTOH, of course one should evaluate existing code first, and not just start a new project because of NIH syndrome)
Maybe you find it boring, but one of the most interesting aspects of life are its beginnings, it's basic building blocks and mechanisms. All this happens on cell level. You don't need more than monads to study it. If we'd find life on mars or elsewhere in the solar system that has common origins with terran life, that would be interesting enough. Finding completely different organisms would be revolutionary and change our worldview forever (I think).
;-)
The two big questions regarding life:
1. is there _any_ life out there? And if, how does it work?
2. Are there "intelligent" life forms we can maybe even communicate with?
Question 1 being answered in my lifetime would suffice for me
> Now if the Gnome guys (and KDE guys, too) could just
> figure out a way to have decent fonts installed by
> default
Well, KDE nor Gnome create or package fonts, so this is up to the distros. The only thing KDE and Gnome can do (or their respective UI toolkits) is ot render the fonts nicely. And even that is mostly business of freetype (who can't implement all the good algorithms due to patents).
> The mouse in its current form is about to be rendered obsolete. > With XGL, Quartz3D, AeroGlass, and Looking Glass, we are most assuredly moving twoards fully-3d > computer enviroments. A bold statement. Do you have any good arguments that suggest such a change? Most HCI and visualization people would disagree. Shneiderman for example, says that 3D is only useful where you have data that is best visualized as 3D. He certainly does not suggest navigation in 3D for everyday tasks. First, having some useful 3D effects using XGL or AeroGlass doesn't mean that the whole environment becomes three-dimensional. For example, the navigation is still 2D for a good reason. The screen is 2D, so is text. Why should text-oriented work be done in 3D? If 3D is really the future, it needs better devices than a 2D screen. And headsets don't cut it, they disconnect you too much from your surroundings. Just because something works out in Doom, doesn't mean it's a good idea for browsing the web, writing e-mails or accounting. There are niches of course where 3D would make sense. But I don't see a reason why usual office work should become full 3D. Without good arguments pro 3D, I continue to think that it's just a pipedream of some 3D enthusiasts (techies), who don't know much about creating interfaces designed for the actual tasks people have to perform.
It's not that "useful" and "good-looking" are alternative. Good technology is both good-looking and useful. Why must a useful device look ugly? If the designer adheres to "form follows function", it should be possible to have a both useful and elegant device.
Well, you can always strip the HTML away. A regexp killing off everything looking like an HTML tag should do.
The far bigger problem for us aggregator authors is that RSS doesn't specify whether the content is HTML or plain text - one just has to guess. Is this just a bracket or is it a tag? Do I have to resolve entities? RSS 0.94 or something contained a type attribute to specify HTML, but the recent RSS 2.0 spec says "the description MAY contain HTML". May contain, may not contain. How stupid is that?
The Atom format is much better specified - and content type is a central attribute (with plain text as default) of the respective tags such as title, summary, content. Unfortunately Atom is bit late now to make it and break the RSS2 dominance.
> I hate KDE because it uses QT. A tool that enforces your resulting work to be
> free doesnot really feel likes a free tool.
You are not forced at all to release your KDE software under GPL. Feel free to purchase a Qt license from Trolltech, and you can release your software under whatever license you want.
> Using javac is the minimum you need to program > java in any environment. It is in fact all you > need, unless you want additional tools. I don't know what the magic is behind javac you want to teach. It's quite simple: javac SomeClass.java; java SomeClass", or similar. You can teach that at the beginning when teaching "Hello World", that is where it fits in. For any bigger project with more than 2 files you better should teach them how to use a build system like ant. I remember myself in my beginnings (mostly in highschool times) writing handmade compile scripts where a Makefile would have been far more appriopriate (and less time-consuming when compiling). If you need to teach specific tools at all, do not spend all the time at this basic level. Start with the basics, yes, but don't stop there, go on to higher-level tools, more appriopriate for building large software systems. Otherwise people will try to build skyscrapers by assembling sandcorns manually.
> It's a shame that RSS couldn't still > be RDF... RDF needs more "killer > apps". First of all, RDF needs a better XML representation. In it's current form, RDF/XML is confusing and hardly human- (or: programmer-)readable. For the average programmer who wants to write a little RSS-processing app and doesn't care about semantic web and the like, RSS2 or Atom are just more clear and less obfuscated. Of course, having 1000 formats and variants is a problem, too. But the basic XML representation of these formats makes simple things simple, RDF does not. I like the RDF model (somewhat, if Reification wasn't that complicated, I would like it even more), but the XML representation sucks for simple purposes like syndication.
> all books have unique identifiers (ISBNs) What is this exactly good for? an ISBN is an ID, and that only helps if I have that ID. I actually never have it when I search for a book. I know the author, or some part of the title etc. > "expert classification" (the Dewey system) So, from where should I know where Dewey's Classification puts the books in? Some expert may say "This book is about A", but I see other aspects B and C. No static, pre-defined classification scheme can catch all possible categorizations that make sense to users. Tagging could help here. Let's see if it is really useful at amazon.
"Free association" means here that there are no pre-defined categories or even hierarchies of terms, but that the user can assign every keyword. About the "innovation" in tagging: No, tagging is not rocket science. It's not the new, great, hyper-complex funky concept that solves all our problems. Fortunately not. It's simple, and that's why it's good. People get it, and people use it, and that's why its useful. The social aspect, letting the "masses" do the categorization is what makes it useful. It's like with most successes on the net: Is HTML rocket science which was never there before? No. There were far more complex hypertext systems which made some researchers rave, but which never took off.
Well, Beagle might be a nice and working implementation (I never used it much and haven't read the code, so I can't tell), but it is not exactly what tenor aims to be. Tenor's primary goal is not about search, but about linking related desktop resources (a resource can be a file, a website, an email, a post-it note, an abstract idea, a person in your address book). So you get a "web of context" which makes it possible to present the user the information is actually interested in in his current context. This is beyond what beagle does: collect metadata, build an index, search it via search string. That is not rocket science, and was there on the web for a decade now. Also, it's limited, it can't find the picture my friend sent me via IM yesterday. Beagle is good because it already works, and tenor is still a concept, but from the idea behind it, Tenor is more compelling IMO. And it's not a Beagle clone by no means.
The folks at OpenUsability supporting OS projects all the time, made several usability reports and gave also useful hints for my project. These reports are not visible on the main site, but you can find them if you browse the project list. The most visible work of the openusability folks will be the KDE4 HIG and usability work there. The openusability people also support developers on KDE usability MLs, IRC, or just face to face on conferences and such. They do a great job, if you don't see much of it at the openusability main site.
The point is, that RSS brings the news to you and you don't have to go for them. Convenience is the key. It's notification vs. polling (well, it polls in the background, but for you as a user it feels like notification). If I have a friend who updates his RSS-enabled webpage once in two weeks, I see it in my RSS reader when it happens instead of visiting his page manually once a week or so to just see that nothing has changed. For slashdot and other high-traffic news sites the benefit isn't that big, but it still makes reading news faster and more convenient, if you use a good RSS reader. I can follow 50 personal homepages and occasional updates blogs without much effort. Do this without RSS. The argument "it's just a simple XML file, so where is point" is not a good one, as every good web technology is simple. Did the WWW take over because it was the most sophisticated technical solution? No, it take over because it scales relatively well (compared to things like gopher) and because its simple. I am sure there were many people like you 15 years ago saying "HTML? It's just a simple text file, so where is the point?".
> Not just use someone elses lego bricks to build > some bloatware system thats has all the > stability and robustness of a 1 legged stool. So you say a system built of "your own sandcorns" is more stable than using "someone elses lego bricks"? Lego bricks being available as libraries are mostly better tested (more eyes) than the stuff you coded for your own. Just look at the security problems with C: Because most C coders have to play with char arrays for string handling instead of using a string class, we have all these buffer overflows all the time. Using a string class that abstracts from the nasty details makes the code less error-prone and more secure. A common string class gets more code review than your own privately used code will ever get. Also, abstractions make the code less complex and thus improve code quality. > Its a bit like car maintenance No, its more like building skyscrapers. Nobody would build them out of sandcorns at the building site. You use components.
> This is a good example of the philosophy of flexibility so pervasive in Gentoo's portage Actually it's a pain in the ass. Apparently it causes a lot of problems, considering the amount of gentoo users that come to the KDE IRC channels, having problems because they haven't got package X installed to get KY working. > In fact, I wouldn't be surprised if someone has made RPMs or DEBs of individual apps. Breaking news: Debian has splitted packages for _years_.
Afaik this will be fixed in kdepim 3.4.2. Which compiler version do you use? I've seen this bug once, and it was from a gcc 2.95 user. But I guess you don't use 2.95, right?
You don't really expect that people will do that work for you? For an overview what is going on right now, check out "this month in SVN": http://www.hoult.org/~canllaith/svn-features/14-07 -05.html