I just read through some papers in Florida and it
seems very likely this election will be over turned. The Associated Press is already reporting that a
lawsuit ;
has been filed.
Further, the lawsuit likely has merit because the
ballots are clearly illegal according to
Florida law.
For a picture of the ballot see this this site. The statue clearly states (emphasis added)
... then the elector shall, without leaving the polling place, retire alone to a booth or compartment provided, and place an "X" mark after the name of the candidate of his or her choice for each office to be filled, and likewise mark an "X" after the answer he or she desires in case of a
constitutional amendment or other question submitted to a vote.
If this isn't enough to call to question the vote I don't know what would be.
I should mention what RedHat did does have some precedence in Unix world. Many proprietary versions of Unix ship two compilers. One is meant
simply to have the features to compile the kernel. It supports few dangerous optimizations and tends to be fast and loose with the rules. They then ship an enhanced compiler with better error checking and more aggressive optimizations.
This is what RedHat did. They shipped a version
modified to be called kgcc and a enhanced version called gcc. So at least on that case, I have no problems. I thing a previous version shipped with gcc 2.7.2 and egcs as well. This is a good way to introduce a new compiler when the kernel is not completely up the error checking standards of the latest compiler.
What they did wrong was failed to consult the gcc steering committee to get approval for a new stable so that other venders can also use it. They also failed to modify the contact
numbers and emails for the compiler such that it
directs problems to RedHat rather than the Gcc group. Third, they failed to roll back those changes to the C++ ABI so that their version would be able to generate code libraries which could be used across platforms. This is bad because it makes shipping C++ libraries more difficult and error prone. Some venders may only chose to ship RedHat versions and thus users of other dists are left in the cold. Also they placed the burden of handing the library problems on the free software developers such as myself without a lot of notice. I only test my software against known stable compiler versions and thus this release caused me some problems.
With all respect to Bob Young, I think that RedHat did make some mistakes. He certainly doesn't deserve the horrible Microsoft comparisons and other flames. However, on issues like shipping snapshots I don't agree with him. Summarily declaring all people who disagree are wrong with him seems quite arrogant. I think RedHat deserves to hear at least on that issue what mistakes they made and where they miscalculated.
Further, I also disagree with RedHat on the production of Inti rather than supporting the GNOME's current C++ binding, Gtk--. That like shipping a version of Gcc which is not compatible is divisive and intrusive into the workings of the Free Software community. A great many people did not see cloning an existing free product nor moving Havoc away from gtk+ development as good for the community. Obviously, RedHat felt it was in their best interests. I do hope that this situation wakes us up to the fact that what companies do is best for them and not necessarily the best for everyone. After all the point of a company is to make money. We should praise a company that does something in our best interest, and point out why we won't support them when they don't. After all it is in a companies best interest to release as little information about what they will support as possible to maintain competitive advantage. At the same time this is really against our interests as free developers such as myself have little chance to fix the bugs that shipping a snapshot compiler causes. However, flaming them like some people have choosen to do helps no one. Constructive criticism is a better approach.
It is in the dist because they wrote it and are hoping to make money off it. It is intended to bring in the ISV dollars as an all in one equivelent of Qt. It is not part of GNOME, nor
complete at this time. Their web site says that. It specifically states this is untested and unsupported snapshots only. Though you be much better to direct questions regarding its use to Havoc.
Gtk-- is also on one of their CDs I believe, though in this case they chose to clone the product rather than support it because they did not feel Gtk-- would meet their requirements. I regret they decided this and felt it was a mistake.
I am not sure that Inti is the best thing to include in a dist at this time and I am surprised they would ship it considering it depends on a version of gtk+ which should not be shipped at this point (or so the installation script says.)
Though considering they shipped snapshot of gcc, I can't say I am surprised. I had seen the 2.96 in the rawhide but figured they were working with the stearing commitee to get a new stable shipped. I was flabergasted that they released with the snapshot and gcc steering hadn't even heard of it.
You should probably note that Inti is not intended
for use currently and is alpha. It is designed to appeal to ISP and is not supposed to compete with the current Free Software offering. I suggest you look at the parent project Gtk-- which runs with todays compilers and gtk+. You will be much happier.
Whether it was a good idea or bad remains to be determined, but at least from what I have seen as a C++ developer on linux, this will just make a bad situation worse.
All C++ libraries destributed in rpm form need to
have a specific dependency against the compiler. That is because we had 2 ABIs in common use. Egcs 1.1 and gcc 2.95.2. With this snapshot and the
gcc 3.0, we will end up with 4 ABI. This will mean the very concept of distributing a C++ library will become a point of frustration. Just ask the distributors of gabber.
I have produced two C++ libraries gtkmm and sigc.
With both I get a constant stream of complaints when someone takes an rpm from one build redhat and places it on another (mandrake). The result
is a bug reported to me that my stuff if broken when if is the linker not saying the ABI is wrong.
Constant problems with the ABI (now 3 floating around and one more on the way), will mean the
C++ programmers even spend more time fighing problems they don't understand. The result will
be more people pissed off with C++ and linux.
In case you think the gcc steering can just
keep the gcc 2.96 ABI, then they will also have to keep a number of outstanding bug reports which
are pending further changes in the ABI. My libraries are slightly cripple with the use of dynamic cast because of those long standing problems.
Qt uses a preprocessor to rip out its own special set of keywords like signals, slots, and emit.
They also require special macros at the top of each class to insert the special code generated from the MOC compiler in.
In other words, their use of the langauge is not
much better that MFC, though at least they don't supply their own compiler. I keep hoping someday
they will give out long standing hacks like that and switch to using the langauge itself to do the same thing. Unfortunately, with Qt TrollTech seems to have gotten the mindset that only they can supply platform independent C++ libraries.
One quick question. Is it possible to build a micro elevator with todays technology? That is a 100 kg mass strapped in geosyncronous orbit connected to the earth with modern carbon fibers capable of taking a 1 kg robot from ground to orbit.
Considering the cost that a large elevator would require, it seems that if we are seriosly considering it we would need to actually build a
micro elevator in advance. It would serve to
prove the stablity of such a design, give us models of the stresses actually experienced, and
serve as a starting point for a larger construction.
If a piece of code is licensed under both GPL and BSD/woa than the user can choose the license they want to use. Most people would choose the freer (to the user) BSD license.
What will get really interesting is what happens when people submit GPL licensed code to the GPL licensed project? The result is the GPL one would fork if the author didn't give permision to use that in the current non-free edition. Thus if TrollTech does dry up, the GPL one cannot revert to BSD, but the entirely TrollTech copyrighted one can.
I agree 100% with his assessment. The KDE crew has made a number of mistakes in not chosing a free software base and then disregarding the licensing issues. Had KDE been a company violating the GPL, we would have been all over them. Instead some people here are agast that he can accuse KDE of doing something wrong.
Notice the all RMS is requesting is for KDE copyright who took code from other GPL projects and gave implicitely permision to link with Qt to ask for forgiveness from the authors they took it from and to clearly add a statement that allowed linking to GPL code in past. How hard is it for KDE to do that? Having recently had to contact all the authors in my project to get code signed over to FSF, I can say that it amounts to just over an hour for each of the lead package developers. I suggest they take the hour and do the appology and link statement.
The problem here is that what RMS asks steps on some people pride. They neither feel it was a mistake to use Qt in the first place nor that
once they had the QPL license that adding an exception was needed. RMS who wrote the license gave you his interpretation. The exception was needed and he is willing to forgive it as soon as Qt is switched to GPL. Get over it, everyone makes mistakes. It is time to clean up and move on.
--Karl
Re:Read before replying.
on
Qt Going GPL
·
· Score: 1
If you decided to use Artistic license because you though it would escape problems, that I think you were misinformed. The problem at the time and always had been KDE developers borrowing code from GPL projects for a GPL project which linked to Qt without permision. The correct solution is to ask for permision or rewite the code. However, a classic response was to ignore it and try to promote the license from LGPL to LGPL with QPL.
Thus the problem wasn't the LGPL, it was the use without permission problem. Switching to Artistic and the denying use of that code on a join theming project (I case I did hear about), sounded a lot like a change just to spite developers. When that happens the code just get rewritten, which is a waste. The whole point of open source licensing was to promote reuse. Now that Qt made the last pludge, I hope the infighting will die.
As for the asymetry, I can't speek for the inconsiderate twits who may or may not be denying KDE use of gtkhtml code. I was speaking about the future and not the past. I don't know the situation, but if it was a case of license promotion then they had a right to ask it to stop.
If they had taken the code originally from KDE, they are being asses. Changing the license to artistic just to prevent use in other GPL code is sinking to the same level. It hurts not just GNOME, but all GPL code which might want to use it. As soon as KDE is fully GPL complient (GPL/LGPL/BSD) licensed developer permision won't be a problem so long as people don't promote a license (GPL->LGPL->BSD). Demotion of licenses is aways allowed.
Admittedly I am biased. I have been told in the past by one KDE developers "how dare I construct something to compete without consulting." That kind of attitude from someone who spouted "it is only about the code" and thus licensing issues should be ignore, gives me some reason to feel there are people in the KDE camp without a clue, in my less than humble opinion. But then KDE isn't immune to this. I am sure there are GNOME coders doing a tit to pay back for some preceived tat. They may well be the boneheads who flame Gtk-- from within the GNOME project just because they don't understand that some people might want to use C++. Just because both sides are engaging in license wars doesn't make either of them look mature. In virtually every case a license gets denided it results in bitterness and a denial the other way often to people who weren't involved in the first dispute. Maybe this will break the cycle. Most KDE developers and even TrollTech employees have not been bad, but KDE really should have cleaned their house up, come with their tail between there legs, gotten permision from all the people whose GPL code they borrowed and gotten themselves included in debian.
If you do know of some code on which copyright was
removed (and the source wasn't licensed in such a way as to allow that), I suggest you back the assertion up with references and campaign to get it fixed. Removal of copyright is not legal and thus unacceptable no mater which camp did it.
Any KDE code which is in the Gtk-- is properly copyrighted even after the code was replaced. I won't speek for GNOME as a whole.
--Karl
Re:Read before replying.
on
Qt Going GPL
·
· Score: 1
I did read! I was addressing the "On another note,....". You are correct that the situation is asymetric with KDE can take GNOME code and not the other way around.
My opinions (which don't represent that of GNOME) are mixed.
Of course, neither project has been particularly good at sharing. Some GNOME people did not grant license to use code the KDE people have wanted (with some reason as Qt wasn't free and the KDE people at that time just assumed they could), and later some KDE people have licensed things with artistic license to prevent use in GNOME. It is childish tit for tat. I don't feel that KDE has a very good track record of respecting licensing issues.
As far as licensing they have shown to be quite clueless.
Closing your eyes and assuming it will go away like they did was short sighted. The fact that Qt actually did release GPL and cleaned up their mess does relieve them of the initial act.
TrollTech on the other hand is quite cleaver in protecting their business model to the benefit of free software. They released as little as they could until Harmony came allong. They released more (ablity to fork code base) which wiped Harmony out. It however, was still not enough for Debian but most people could ignore that. Had GNOME not pressed on it would have remained that way. Then when KDE appears to be losing some ground to GNOME, they release it as GPL (ablity to port to other platforms). It is good for KDE and for free software, but it is too late to heal the frictions caused. Merging Gtk+/Qt won't happen because a GPL licensed GUI in a field with many LGPL GUI is not a value added. It also shows that there gamble that the QPL would be enough was not enough to keep KDE ahead politically. Had they released with GPL at 2.0, it may have made a larger difference. That should be a valuable lesson to other companies, if you want to be free do it with GPL. Less arguing and larger acceptance.
For TrollTech latest gift, we should certainly thank them.
--Karl
Re:Now GNOME code can be copied to KDE!
on
Qt Going GPL
·
· Score: 1
Quick note. The Gtk+ C++ bindings are called gtkmm and are included in GNOME. The Redhat project called Inti is to create a C++ framework and is not at this time part of GNOME. Neither Inti nor gtkmm can copy Qt code, because you may not shift the license from GPL to LGPL without permission. Also as both the C++ bindings have more modern implementations than Qt, the bulk of Qt code wouldn't be all that much use.
You hit the nail on the head. Gtk-- punted for flexiblity to allow all of those styles you named because the nature of C++ is that the programmer chooses the memory style. This is both a good thing and a very bad thing. However, this is fitting with all of C++ nature.
Instead others argue that the memory management should be chosen by the library and thus we should fall back to the lowest common denominator all dynamic. If that is true than the programmer should just go use Java because only there with pure language supported GC can you possiblely get away with that attitude. I reject that notion entirely.
What Guillaume didn't mention is that prior to me taken my rather stuborn stance, I had very good C++ programmers within the Gnome community evaluate both the Gtk-- system and Havoc's proposed system. Gtk-- had a number of admitted flaws and features. Havocs had full say as to waht he felt was good and bad with his and mine. However, the experts felt that Gtk-- despite the flaws was a better and more workable idea. I was prepared to leave the decision to a neutral arbitor for the good of the community.
Havoc rejected this and did his own thing or actually what he was ordered by his pay masters. At that point is was quite apparent that Havoc was not acting with the input or best interest of the community. Thus I refuse to hand over the reins of Gtk-- to him. What good is discussion and community input when the all mighty dollar will just roll over that which is the best technical solution? I work on Gtk-- for my own enjoyment. Having one persons opinion and that of his boses without the freedom to disagree or take input from others rammed down my throat is not what I consider fun. Guillaume can complain all he wants about my decision not to fold Gtk--, but I feel strongly that I should stand on my principles because it is my principles which make me what I am.
For those that like Inti please use it. For those
that like Gtk-- use it instead. But don't mistake Inti for a community project. It isn't even close.
I am sorry that you felt that gtk-- style was too far from your own. Gtk-- depends on feedback from the users to get the style it has. Those interfaces you named were removed because they were totally unsafe (that is they would take pages of documentation to use safely). I hope the replacement would be better, if it wasn't I am sorry. However, as you never sent any comments to tell me that you felt it was a problem I can't really see how you have room to complain.
Had you sent some input you would have gotten a better system. But honestly I believe the current gtk-- system produces the less than 20 line result you are looking for. (though yes some templates are required.) I think you were thinking much to much that what is in gtk-- is a final design rather whan what it is in reality a set of experiments to be wittled down and evaluated by the community.
Okay troll I will bite and as one of 2 people who know the whole story this is as straight of answer as you will get.
The author in question is a Qt fan and always was. He participated for personal reasons such as helping out the under dog and because that is what a project he worked on planned to use. Just because someone admires one piece of work doesn't mean they necessarily consider their work poor. I for one am a big fan of FLTK, however, I feel that the model is just a bit too small in terms of callbacks and flexiblity which is why I work on Gtk--. He was leaving the project whether this conflict occured or not. He had simply run out of time to do a good job. The fact that inti came allong simply provided him with an acceptable out. I am sorry that our time ended on such poor terms. There is a fair more to the story which was not in his editorial. To my knowledge, he is not working on any widget project nor does he plan to. Inti is
supported by redhat alone and has completely conflicting goals with a community supported project like gtk--.
There were 5 people on the project at the peak with Tero Pulkkinen, Todd Dukes,
Guillaume Laurent, Karl Nelson, and Havoc Pennington. However, that number had dwindled to one largely beacuase gtk-- was a very large an ambitious project and because the people we were constructing it for were largely indifferent. The Gnome organization was constantly telling users use gtk+ not gtk-- and after a long time that became very hard to bare. Both Guillaume and I contemplated quiting many times both because our work was largely ignored with constant replications of our work and the fact that people within Gnome actively told other Gnome projects who could have provided the project with support we needed to get the job done right not to use or help us.
As far as Qt is concerned, I doubt they know or care. Gtk-- is and always will be a community project not a commercial enterprise. We were never really any threat to them. However, we actively tried to reach standards above those of their comercial kit. You can't fault us for the effort.
As to how much has Gtk-- copies from Qt, nothing! Gtk-- had a signal system which was based on gtk+ and the impressive work of acedemics. Please go look at the libsigc++ homepage under links to see all of the systems which were studied to make the gtk-- signal system. The only thing used from Qt that I reviewed was the documentation on the signal slot system to see what they were capable of when I redid the design. Had you read the benchmark page off the libsigc++ homepage, you would find gtk-- uses a totally different technology. Qt is string based, gtk-- is template based. This is a night and day difference.
As for how many gtk-- apps there are that would be over a dozen public projects. The most recent and most sucessful of which is Gabber.
In reading the interview I can only conclude that Dickinson doesn't understand the concepts of patents and copyrights in the slightest. He may be a lawyer but the differences in law clearly escape him. At one point, he makes inference that it is better that software gets patented than copyrighted because that would ensure use in less time. Then when Tim disagrees, he simply cuts him off. Dickinson statemeet is clearly untrue.
A simple examination of the rights thus far given in the courts to copyrights and patents shows this is clearly false. For example, if I copyright my implementation of an algorithm then all who see it must not duplicate it for the duration of my copyright (which is a very long time thanks to disney.) If I patent that same algorithm then yse it will become public domain in considerably less time. At least on the front, it is true.
However, the effects during those years under patent are vastly different. Under the copyright, someone can come up with an identical output with an independent implementation without ever having seen my original and they are completely free to use it. That is a patent places a mortorium on all use of works which perform the same unique function. Boy doesn't Disney wish they could have patented Mickey, then all drawings of mouse cartoons would have been restricted to only them!
If this is the kind of reasoning that is given to allow software patents, then I think the useful age of the patent system is long past.
Actaully in the few times I have faced a DoS attacks, we did manage to track the users down. Just because they are forging the packets does not mean that their machine was able to avoid contacting the target completely.
In our case, we tracked the user down to his source by the "other" packets which he sent. The person sending the DoS often will send a ping and/or a name lookup of similar request prior to the attack or each time they add a new host in. Although it is a considerable exercise in collecting enough data to figure out which connects were real "valid" user contacts and which came from the kiddies. As a result we managed to isolate the DoS to specific hosts and subaddress ranges.
Of course, if you are into real fun assuming that you can get one of their target machines (which using a DoS scanner and a rough idea what subnet they are in) you can often port scan for eggdrop bots and other toys. Once you can convince a physical sysadmin to send you those files you then have a map of the kiddies entire bot and DoS network. Once I reach this stage I then post guards on IRC channels which their bots used and with a small ammount of detective work get their ISP. Script kiddies like to brag about what they do and it enevitably leads then them to surrender their identities.
In all the cases in which I managed to get that level of penitration into the kiddies network, I always managed to shut them down. ISP are very friendly about taking out malicious users especially when you supply logs and the attackers home address.:-) I even have gotten offers to have the attacker arrested (to bad I don't have the cash to fly there and file charges). Thus I can conclude although it is not an easly task it is not entirely necessarily impossible. (That is assuming your attackers are 14 year old kids and not paid professionals.)
Since you are into the math, would the entire Earths arsonal be enough to knock the atmospher of Venus enough to stop the green house effect there and cause huge rain of sulfuric acid seas to form? After all since there is no question there isn't any life there and we might as well look at terraforming value. (Assume nukes detonated in high atmospher to create plasma which escapes or if you perfer surface nukes to increase the ammount of dusk to a nuke winter.)
True, but lack of driver support now does not seem like a good reason to go and creat another whole 2D model (which will be inconsistant with what has become the 3d standard), and forces duplication of effort. There is nothing in the OpenGL concpet that forces use of 3d. One could take the 2d operations of OpenGL optimize drivers for them and then use it as the basis X primative replacement.
Lets not confuse representation with implementation. OpenGL can "represent" all of the features we want, but perhaps doesn't "implement" them all well. I think Berlin made the right choice when they realized they could choose anything which allowed representation of concepts they needed after all the optimized implementations will come later.
Arguments about what in OpenGL can be accelerated applies to both this new standard and the old, and thus are meaningless in the context here. OpenGL supports concept of antialiasing. Only some hardware supports it. This will be true regardless of what protocol the data is sent in.
You can skip the current OpenGL implementation, but skipping the conceptual parts that OpenGL presents seems off. OpenGL is also extendable thus such thinks as a better 2d transparency or font model could be added without need of fresh start. This would make for a more consistant platform overall.
Why not just make OpenGL (GLX) the new standard for X graphics primatives? It contains virtually all of the required elements including subpixel accuracy, antialiasing, and alpha channel. Thus why reinvent the wheel with a very good one already exists? Additional things like font model would be added as extensions is needed assuming they don't already exist. Simply slip Xlib into window handling and old primatives and switch to GL as the primative routines.
Maybe it is a April fools joke, but if it is everyone is taken.
Clearly, this is a very bad thing for Microsoft as a company (who knows about the stockholders.) The decision will be released and can be used in other Microsoft trials. Settlement was really in their best interest.
Am I the only one who thinks that their method of even planning out these trips is off? It seems to me that the first set of the process is to establish a permanent communication site on Mars. Simply designing a construction a medium grade interplanetary communication satellite and sending 10 or so of them into Mars orbit should be the first step. They can be largely boiler plate designs without any scientific alterations. The planning stage consists just of how to get them into orbit and get communications established. (Too bad the irridium satellites can't just be relocated.) If you are really good you build them with large data storage node capablity so that you can use them to provide good data streaming when the probes generate more data then can be uploaded to earth in the time windows. They also would be able to communicate to one another to provide for probes on the far side of Mars at any time. If we got enough of them there we could even set up a Mars GPS which makes guiding semiatomous robots much easier. Further, they themselves could provide to make a IPPS (interplanetary positioning system) which would make delivering probes into proper orbit a snap.
With such a system the cost of sending a probe drops incredibly. You don't need to design earth contacting hardware from the surface of Mars. Instead the hardware need be little more powerful than a headset and still have good data rates.
Instead we send a spattering of probes which we must get full scientific data out which serve communications only as a second purpose. The loss of these communication satellites wouldn't bee a big deal as we can always send other to take its place.
Slashdot Mirror
For a picture of the ballot see this this site. The statue clearly states (emphasis added)
If this isn't enough to call to question the vote I don't know what would be.
--Karl
1. Enter earnings ______________ (I)
(sum of all capital gains, interest, wages, and all other earnings minus capital loses)
2. Compute rate using
R = 0.6 - 0.9*exp(-I/100000) some tweeking needed
______________ (R)
3. If R is less than 0 you owe nothing, stop.
4. Multiply I times R. Mail it in as your yearly tax.
______________
See nice and simple, can be sent on a postcard. Of course, under this system selling a house would be murder. ;-) You like that better?
--Karl
--Karl
What they did wrong was failed to consult the gcc steering committee to get approval for a new stable so that other venders can also use it. They also failed to modify the contact numbers and emails for the compiler such that it directs problems to RedHat rather than the Gcc group. Third, they failed to roll back those changes to the C++ ABI so that their version would be able to generate code libraries which could be used across platforms. This is bad because it makes shipping C++ libraries more difficult and error prone. Some venders may only chose to ship RedHat versions and thus users of other dists are left in the cold. Also they placed the burden of handing the library problems on the free software developers such as myself without a lot of notice. I only test my software against known stable compiler versions and thus this release caused me some problems.
With all respect to Bob Young, I think that RedHat did make some mistakes. He certainly doesn't deserve the horrible Microsoft comparisons and other flames. However, on issues like shipping snapshots I don't agree with him. Summarily declaring all people who disagree are wrong with him seems quite arrogant. I think RedHat deserves to hear at least on that issue what mistakes they made and where they miscalculated.
Further, I also disagree with RedHat on the production of Inti rather than supporting the GNOME's current C++ binding, Gtk--. That like shipping a version of Gcc which is not compatible is divisive and intrusive into the workings of the Free Software community. A great many people did not see cloning an existing free product nor moving Havoc away from gtk+ development as good for the community. Obviously, RedHat felt it was in their best interests. I do hope that this situation wakes us up to the fact that what companies do is best for them and not necessarily the best for everyone. After all the point of a company is to make money. We should praise a company that does something in our best interest, and point out why we won't support them when they don't. After all it is in a companies best interest to release as little information about what they will support as possible to maintain competitive advantage. At the same time this is really against our interests as free developers such as myself have little chance to fix the bugs that shipping a snapshot compiler causes. However, flaming them like some people have choosen to do helps no one. Constructive criticism is a better approach.
--Karl
Gtk-- is also on one of their CDs I believe, though in this case they chose to clone the product rather than support it because they did not feel Gtk-- would meet their requirements. I regret they decided this and felt it was a mistake.
I am not sure that Inti is the best thing to include in a dist at this time and I am surprised they would ship it considering it depends on a version of gtk+ which should not be shipped at this point (or so the installation script says.) Though considering they shipped snapshot of gcc, I can't say I am surprised. I had seen the 2.96 in the rawhide but figured they were working with the stearing commitee to get a new stable shipped. I was flabergasted that they released with the snapshot and gcc steering hadn't even heard of it.
--Karl
--Karl
All C++ libraries destributed in rpm form need to have a specific dependency against the compiler. That is because we had 2 ABIs in common use. Egcs 1.1 and gcc 2.95.2. With this snapshot and the gcc 3.0, we will end up with 4 ABI. This will mean the very concept of distributing a C++ library will become a point of frustration. Just ask the distributors of gabber.
I have produced two C++ libraries gtkmm and sigc. With both I get a constant stream of complaints when someone takes an rpm from one build redhat and places it on another (mandrake). The result is a bug reported to me that my stuff if broken when if is the linker not saying the ABI is wrong.
Constant problems with the ABI (now 3 floating around and one more on the way), will mean the C++ programmers even spend more time fighing problems they don't understand. The result will be more people pissed off with C++ and linux. In case you think the gcc steering can just keep the gcc 2.96 ABI, then they will also have to keep a number of outstanding bug reports which are pending further changes in the ABI. My libraries are slightly cripple with the use of dynamic cast because of those long standing problems.
--Karl
In other words, their use of the langauge is not much better that MFC, though at least they don't supply their own compiler. I keep hoping someday they will give out long standing hacks like that and switch to using the langauge itself to do the same thing. Unfortunately, with Qt TrollTech seems to have gotten the mindset that only they can supply platform independent C++ libraries.
--Karl
Considering the cost that a large elevator would require, it seems that if we are seriosly considering it we would need to actually build a micro elevator in advance. It would serve to prove the stablity of such a design, give us models of the stresses actually experienced, and serve as a starting point for a larger construction.
--Karl
What will get really interesting is what happens when people submit GPL licensed code to the GPL licensed project? The result is the GPL one would fork if the author didn't give permision to use that in the current non-free edition. Thus if TrollTech does dry up, the GPL one cannot revert to BSD, but the entirely TrollTech copyrighted one can.
--Karl
Notice the all RMS is requesting is for KDE copyright who took code from other GPL projects and gave implicitely permision to link with Qt to ask for forgiveness from the authors they took it from and to clearly add a statement that allowed linking to GPL code in past. How hard is it for KDE to do that? Having recently had to contact all the authors in my project to get code signed over to FSF, I can say that it amounts to just over an hour for each of the lead package developers. I suggest they take the hour and do the appology and link statement.
The problem here is that what RMS asks steps on some people pride. They neither feel it was a mistake to use Qt in the first place nor that once they had the QPL license that adding an exception was needed. RMS who wrote the license gave you his interpretation. The exception was needed and he is willing to forgive it as soon as Qt is switched to GPL. Get over it, everyone makes mistakes. It is time to clean up and move on.
--Karl
As for the asymetry, I can't speek for the inconsiderate twits who may or may not be denying KDE use of gtkhtml code. I was speaking about the future and not the past. I don't know the situation, but if it was a case of license promotion then they had a right to ask it to stop. If they had taken the code originally from KDE, they are being asses. Changing the license to artistic just to prevent use in other GPL code is sinking to the same level. It hurts not just GNOME, but all GPL code which might want to use it. As soon as KDE is fully GPL complient (GPL/LGPL/BSD) licensed developer permision won't be a problem so long as people don't promote a license (GPL->LGPL->BSD). Demotion of licenses is aways allowed.
Admittedly I am biased. I have been told in the past by one KDE developers "how dare I construct something to compete without consulting." That kind of attitude from someone who spouted "it is only about the code" and thus licensing issues should be ignore, gives me some reason to feel there are people in the KDE camp without a clue, in my less than humble opinion. But then KDE isn't immune to this. I am sure there are GNOME coders doing a tit to pay back for some preceived tat. They may well be the boneheads who flame Gtk-- from within the GNOME project just because they don't understand that some people might want to use C++. Just because both sides are engaging in license wars doesn't make either of them look mature. In virtually every case a license gets denided it results in bitterness and a denial the other way often to people who weren't involved in the first dispute. Maybe this will break the cycle. Most KDE developers and even TrollTech employees have not been bad, but KDE really should have cleaned their house up, come with their tail between there legs, gotten permision from all the people whose GPL code they borrowed and gotten themselves included in debian.
If you do know of some code on which copyright was removed (and the source wasn't licensed in such a way as to allow that), I suggest you back the assertion up with references and campaign to get it fixed. Removal of copyright is not legal and thus unacceptable no mater which camp did it. Any KDE code which is in the Gtk-- is properly copyrighted even after the code was replaced. I won't speek for GNOME as a whole.
--Karl
My opinions (which don't represent that of GNOME) are mixed. Of course, neither project has been particularly good at sharing. Some GNOME people did not grant license to use code the KDE people have wanted (with some reason as Qt wasn't free and the KDE people at that time just assumed they could), and later some KDE people have licensed things with artistic license to prevent use in GNOME. It is childish tit for tat. I don't feel that KDE has a very good track record of respecting licensing issues. As far as licensing they have shown to be quite clueless. Closing your eyes and assuming it will go away like they did was short sighted. The fact that Qt actually did release GPL and cleaned up their mess does relieve them of the initial act.
TrollTech on the other hand is quite cleaver in protecting their business model to the benefit of free software. They released as little as they could until Harmony came allong. They released more (ablity to fork code base) which wiped Harmony out. It however, was still not enough for Debian but most people could ignore that. Had GNOME not pressed on it would have remained that way. Then when KDE appears to be losing some ground to GNOME, they release it as GPL (ablity to port to other platforms). It is good for KDE and for free software, but it is too late to heal the frictions caused. Merging Gtk+/Qt won't happen because a GPL licensed GUI in a field with many LGPL GUI is not a value added. It also shows that there gamble that the QPL would be enough was not enough to keep KDE ahead politically. Had they released with GPL at 2.0, it may have made a larger difference. That should be a valuable lesson to other companies, if you want to be free do it with GPL. Less arguing and larger acceptance.
For TrollTech latest gift, we should certainly thank them.
--Karl
--Karl
Instead others argue that the memory management should be chosen by the library and thus we should fall back to the lowest common denominator all dynamic. If that is true than the programmer should just go use Java because only there with pure language supported GC can you possiblely get away with that attitude. I reject that notion entirely.
What Guillaume didn't mention is that prior to me taken my rather stuborn stance, I had very good C++ programmers within the Gnome community evaluate both the Gtk-- system and Havoc's proposed system. Gtk-- had a number of admitted flaws and features. Havocs had full say as to waht he felt was good and bad with his and mine. However, the experts felt that Gtk-- despite the flaws was a better and more workable idea. I was prepared to leave the decision to a neutral arbitor for the good of the community.
Havoc rejected this and did his own thing or actually what he was ordered by his pay masters. At that point is was quite apparent that Havoc was not acting with the input or best interest of the community. Thus I refuse to hand over the reins of Gtk-- to him. What good is discussion and community input when the all mighty dollar will just roll over that which is the best technical solution? I work on Gtk-- for my own enjoyment. Having one persons opinion and that of his boses without the freedom to disagree or take input from others rammed down my throat is not what I consider fun. Guillaume can complain all he wants about my decision not to fold Gtk--, but I feel strongly that I should stand on my principles because it is my principles which make me what I am.
For those that like Inti please use it. For those that like Gtk-- use it instead. But don't mistake Inti for a community project. It isn't even close.
--Karl
Gtkmm Maintainer
Had you sent some input you would have gotten a better system. But honestly I believe the current gtk-- system produces the less than 20 line result you are looking for. (though yes some templates are required.) I think you were thinking much to much that what is in gtk-- is a final design rather whan what it is in reality a set of experiments to be wittled down and evaluated by the community.
--Karl
The author in question is a Qt fan and always was. He participated for personal reasons such as helping out the under dog and because that is what a project he worked on planned to use. Just because someone admires one piece of work doesn't mean they necessarily consider their work poor. I for one am a big fan of FLTK, however, I feel that the model is just a bit too small in terms of callbacks and flexiblity which is why I work on Gtk--. He was leaving the project whether this conflict occured or not. He had simply run out of time to do a good job. The fact that inti came allong simply provided him with an acceptable out. I am sorry that our time ended on such poor terms. There is a fair more to the story which was not in his editorial. To my knowledge, he is not working on any widget project nor does he plan to. Inti is supported by redhat alone and has completely conflicting goals with a community supported project like gtk--.
There were 5 people on the project at the peak with Tero Pulkkinen, Todd Dukes, Guillaume Laurent, Karl Nelson, and Havoc Pennington. However, that number had dwindled to one largely beacuase gtk-- was a very large an ambitious project and because the people we were constructing it for were largely indifferent. The Gnome organization was constantly telling users use gtk+ not gtk-- and after a long time that became very hard to bare. Both Guillaume and I contemplated quiting many times both because our work was largely ignored with constant replications of our work and the fact that people within Gnome actively told other Gnome projects who could have provided the project with support we needed to get the job done right not to use or help us.
As far as Qt is concerned, I doubt they know or care. Gtk-- is and always will be a community project not a commercial enterprise. We were never really any threat to them. However, we actively tried to reach standards above those of their comercial kit. You can't fault us for the effort.
As to how much has Gtk-- copies from Qt, nothing! Gtk-- had a signal system which was based on gtk+ and the impressive work of acedemics. Please go look at the libsigc++ homepage under links to see all of the systems which were studied to make the gtk-- signal system. The only thing used from Qt that I reviewed was the documentation on the signal slot system to see what they were capable of when I redid the design. Had you read the benchmark page off the libsigc++ homepage, you would find gtk-- uses a totally different technology. Qt is string based, gtk-- is template based. This is a night and day difference.
As for how many gtk-- apps there are that would be over a dozen public projects. The most recent and most sucessful of which is Gabber.
--Karl Nelson
Gtkmm Maintainer
A simple examination of the rights thus far given in the courts to copyrights and patents shows this is clearly false. For example, if I copyright my implementation of an algorithm then all who see it must not duplicate it for the duration of my copyright (which is a very long time thanks to disney.) If I patent that same algorithm then yse it will become public domain in considerably less time. At least on the front, it is true.
However, the effects during those years under patent are vastly different. Under the copyright, someone can come up with an identical output with an independent implementation without ever having seen my original and they are completely free to use it. That is a patent places a mortorium on all use of works which perform the same unique function. Boy doesn't Disney wish they could have patented Mickey, then all drawings of mouse cartoons would have been restricted to only them!
If this is the kind of reasoning that is given to allow software patents, then I think the useful age of the patent system is long past.
--Karl (holder of 1 software patent)
In our case, we tracked the user down to his source by the "other" packets which he sent. The person sending the DoS often will send a ping and/or a name lookup of similar request prior to the attack or each time they add a new host in. Although it is a considerable exercise in collecting enough data to figure out which connects were real "valid" user contacts and which came from the kiddies. As a result we managed to isolate the DoS to specific hosts and subaddress ranges.
Of course, if you are into real fun assuming that you can get one of their target machines (which using a DoS scanner and a rough idea what subnet they are in) you can often port scan for eggdrop bots and other toys. Once you can convince a physical sysadmin to send you those files you then have a map of the kiddies entire bot and DoS network. Once I reach this stage I then post guards on IRC channels which their bots used and with a small ammount of detective work get their ISP. Script kiddies like to brag about what they do and it enevitably leads then them to surrender their identities.
In all the cases in which I managed to get that level of penitration into the kiddies network, I always managed to shut them down. ISP are very friendly about taking out malicious users especially when you supply logs and the attackers home address. :-) I even have gotten offers to have the attacker arrested (to bad I don't have the cash to fly there and file charges). Thus I can conclude although it is not an easly task it is not entirely necessarily impossible. (That is assuming your attackers are 14 year old kids and not paid professionals.)
--Karl
Just a thought.
--Karl
Lets not confuse representation with implementation. OpenGL can "represent" all of the features we want, but perhaps doesn't "implement" them all well. I think Berlin made the right choice when they realized they could choose anything which allowed representation of concepts they needed after all the optimized implementations will come later.
Arguments about what in OpenGL can be accelerated applies to both this new standard and the old, and thus are meaningless in the context here. OpenGL supports concept of antialiasing. Only some hardware supports it. This will be true regardless of what protocol the data is sent in.
You can skip the current OpenGL implementation, but skipping the conceptual parts that OpenGL presents seems off. OpenGL is also extendable thus such thinks as a better 2d transparency or font model could be added without need of fresh start. This would make for a more consistant platform overall.
--Karl
--Karl
Maybe it is a April fools joke, but if it is everyone is taken.
Clearly, this is a very bad thing for Microsoft as a company (who knows about the stockholders.) The decision will be released and can be used in other Microsoft trials. Settlement was really in their best interest.
--Karl
With such a system the cost of sending a probe drops incredibly. You don't need to design earth contacting hardware from the surface of Mars. Instead the hardware need be little more powerful than a headset and still have good data rates.
Instead we send a spattering of probes which we must get full scientific data out which serve communications only as a second purpose. The loss of these communication satellites wouldn't bee a big deal as we can always send other to take its place.
--Karl