But I'm curious. --Were the accounts you were swapping money between two Paypal accounts, or were you trying to move money from a Paypal account to a regular bank account?
It was between two Paypal accounts. You know the really nasty thing? First they froze the destination account, then waited long enough for my bank to transfer my money into the source account, *then* froze it there. Ensuring they had something to collect interest on while they gave me the runaround. How do you like that for evil?
(My company is getting into Paypal regardless of my repeated cautions.)
Paypal currently has several thousand dollars of mine tied under a 'restriction', when all I tried to do was transfer the money from my account to one of my familly members. This worked perfectly with a small amount of money, but the larger amount has caused me extreme grief. Paypal has had the money for a week now, and they refuse to return it to the original account (mine), even though I have jumped through all the hoops they set out for me - some of them several times. They have sent me on a wild goose chase of busy fax machines and even busier phone numbers, so that I can 'appeal' their 'restriction' of my funds. They requested documentation be sent by fax, to prove I am the owner of the account, and I did - three times. Dozens of emails went unanswered. Finally one email arrived informing me that my case would be forwarded to the 'appeals' department within 48 hours. No word on how long it would stay there. In the meantime, Paypal has my money, and is collecting interest on it.
I believe that Paypal is intentionally going slow, and that much of the procedure they have imposed on me is merely a pretext to allow them to keep my money for a longer period, and collect interest on it. This is done under the guise of fraud protection, but I ask you, what harm would there ever be in returning money to its original owner, even if there was some suspicion that the money was not in fact transferred by the original owner. (In my case of course it was.) They collect the profits while I wonder if I will ever see my money again. It does not help to know that Paypal is not regulated as a bank, in fact, not regulated at all.
Will Paypal compensate me for my time and expense in retrieving my money? Will they ever give me my money back? You tell me. I do not know. At this point, I would like to sue Paypal, if I could figure out how to do it. Unfortunately, I am not a U.S. citizen, and so I can not join one of the class action suits currently in progress against Paypal.
I have only one more thing to say at this point: do not use Paypal.
"I know this will start a heated debate, but if my tax dollars are paying for something, I want it issused so that some value comes back, not just a welfare-like giveaway."
Who cares what you want?;-)
Brilliant, that's billg's main argument too!
If *MY* tax dollars are paying for something I damn well want to be able to use the fruits of that work any way I please - including in ways which are NOT GPL compatible.
Right. So if your tax dollars pay for a park, you want to be able to use it any way you want, including putting up a fence around a piece of it, and running strangers off your new-found property.
I just pointed out the lunacy that GPL'd code leads to interoperability. It doesn't because it's unusable by developers who use alternative licenses.
Compatibility and interoperability are best achieved by releasing code that can be used by the widest audience possible. If compatability is your goal you should try to eliminate any barriers at all that exist between the shared code and the developers who can use it.
The GPL strives to do lots of things but compatability and interoperability aren't on that list.
Sorry, Linux itself is the classic counterexample to your argument. Just because of the sheer number of programmers working on it, Linux has come to overshadow all other forms of Unix, and to impose on them a level of interoperability that has never existed before. That is, everybody who wants their Unix variant to survive needs to be able to run programs written for Linux, and thus needs to support the Linux system calls accurately and completely. One by one, all the traditional Unixen are fall into line, or they die.
Poof! Interoperability, by sheer force of will of those programmers who are so strongly motivated to work under the GPL (and thus prevent their own intellectual property from being taken away from them and the public to whom they beqeathed it) that they built Linux into the best operating system ever.
This scenario is likely to be played out over and over again, wherever there is fragmentation of standards due to proprietary interests. After all, it was proprietary interests that caused Unix to fragment in the first place. This evil has now been undone.
For some reason, I can't help but think amd's ceo has a valid point here. Would (almost) every home have a pc if microsoft didn't exist?
Yes, certainly. The day the IBM PC came out, thousands of competent professions knew exactly what they were looking at: the first personal computer capable of doing the things that were at the time being done on minicomputers. We jumped on it immediately, and believe me, Microsoft was never an essential part of that. If msdos never existed, we would have quickly produced something else - probably better - and effected the PC revolution without Microsoft. Microsoft was never essential at all, in fact they did more to slow down development than most people realize. Perhaps somebody can explain to me how Microsoft's macro assembler was delayed for a number of months, and no assembler released by IBM in that time, in spite of the fact that it obviously existed, and had been used to build Microsoft's own compiler offerings? Microsoft came out of that with a comfortable lead over all other tool builders and never looked back.
By my reckoning, Microsoft has already held back the evolution of software by 10 years over the last 20, and with their current level of suppression of independent effort, that pattern is likely to continue.
I'll assume that to mean that previously, you've bought AMD rather than Intel for political reasons. And I'll also assume that to mean that in the future you won't buy AMD because they've sunken down, politically, to an Intel-like level (although I wouldn't go that far, myself).
If so, however, why wouldn't you buy AMD, if they are (at the time of purchase) producing the best chips?
In my case it's simple: I feel betrayed. Up till now I've been willing to overlook AMD's shortcomings and dwell on the advantages. Once burned, twice shy. AMD has demonstrated its willingnes to toss us to the wolves, so...
I think that given the XBOX has has questionable market acceptance, that the damage done in supporting microsoft is far worse than the potential gain in chip sales through what is still a vapor product (and seeks to eliminate Nvidia for some odd reason in favor of ATI).
Oh yes, they just lost me. Up till now I'd been planning to design twin Athlons into a server product, in spite of the poor heat situation. Now it's AMD out, Intel in, thanks a lot for helping me make that decision AMD.
If political considerations are more important to you, consider writing your own open source SVG authoring tool -- for Linux only, of course -- and nuts to your users.
Even though the W3C has backed away from the proposal to include RAND-licenced patented material in W3C standards, the SVG standard went to 1.0 under the assumption that the public would accept RAND-licensing for web standards, and so SVG incorporates a number of RAND-liceneced patents, specifically from IBM Kodak and Quark. No doubt this situation is going to be resolved, especially if people don't forget it still needs to be resolved. To remind the W3C and the companies involved that this situation is still unresolved, you can comment on this list, subscribe here.
And oh by the way, is IBM's roll in this particular little minidrama hypocritical, given their support for and reliance upon Linux and other open source projects? You bet it is, and that's because IBM has lots of little parts, not all of which are headed in the same direction, e.g., some are run by the legal department or managers who still don't get it.
It might even be something that happens just as often on with the combination patch as with the low-latency patch, except the combo got lucky.
If you'd actually read the article you'd know that this can't happen with the preempt patch + low-latency, not unless a spinlock gets jammed, then you have much worse problems. The preempt patch takes care of scheduling events that occur during normal kernel execution (and it does this much more reliably than the low latency patch) but since preemption isn't allowed while spinlocks are held, it can't do anything about latency due to spinlocks. This explains the apparently worse performance of the preempt patch - you're just seeing the spinlock latency there.
The low latency patch breaks up the spinlocks with explicit scheduling points, which is pretty much the only approach possible without really major kernel surgery. That's why the combination works so well. In fact, the parts of the low latency patch that aren't connected with breaking up spinlocks aren't doing anything useful and should be omitted. The worst-case performance won't change.
Yahoo has done well by me. The mail service has been really good about always being there, *never* losing a mail, service interruptions very rare, and as I recall, being due to DoS attacks more often than not.
Even though I don't need the account any more as an 'on the road' kind of thing, since I got to the state of cluefulness to be able to deal with mail without the help of an ISP, I just don't mind making a small investment to maintain the service. In my opinion, Yahoo is one of the less evil companies around and so, here's my nickel.
Another factor in this is... I don't mind sending mail with Yahoo branding, it's not nearly as embarrasing as say, showing up in somebody's mailbox wearing Hotmail noseglasses.
I never used the scripts, I just followed the instructions. Pretty easy, although it did take a long while to download and build. Never used cvs before then.
http://www.kde.org/kde2-and-kde3.html
http://www.kde.org/install-source.html
Helped also. Persevere and it will pay off. You learn a bit about cvs, about writing scripts and you get latest KDE which is always better than releases;-) You can always get help on mailing lists or from google if you have trouble.
Sorry, this just isn't as easy or fast as:
1) install the headers
2) grab the tarball
3) unpack the tarball
4)./configure
5) make
And puts way less load on your disk. Think about it: if it was so easy, then why are there only 4-6 active contributors?
I see a some people making the mistake of thinking that cvs and tarballs are mutually exclusive. They're not. Every so often, preferably at some point release a core developer runs a script to pull tarballs for each app out of the tree. If this isn't possible then the project framework is seriously borked anyway.
Then people who want to contribute have the choice of sending patches against the tarballs or joining the hardcore team and syncing up with cvs. Which isn't as good an idea as it sounds, it's not particularly easy to do productive work when the whole system is changing all the time, and maybe you're not a core developer so you don't know what's happening, why or when. Much easier to work with a stable point release, then when you have something you like send the patch to somebody with cvs access. If they blackhole it, find another project, if they accept it, you're on your way, one day you'll have cvs.
It's a big mistake to make every possible contributor go through the same pain that a core developer has to, to sync up with the bleeding edge.
Funny, I switched from RedHat to FreeBSD due to a seemingly endless line of RPM dependancy issues, config files that seem to defy all logic, and a directory structure that feels like your totally lost in a video game maze.
There are scripts linked to at the bottom of the page that do everything for you as well (one is in webcvs.kde.org).
I know about that page and those scripts. It still takes hours, if you don't believe me try it. (Make sure you're a newbie to kde building first, otherwise your data is suspect.)
Tarballs generally unpack and install in a few minutes and the compile generally works the first time. I'm sorry, but cvs + futzing with scripts that are broken half the time is just not like that.
KOffice is a set of components, not a monolith. KDE uses a component based development model. Thus each of these "applications", kword, kspread, kpresenter, etc, are kparts. You can work on one and never even see the source for the rest. They are just released together as a bundle by the KDE project.
That's exactly the problem. Break each application out as a tarball instead of requiring people to deal with the whole bundle and the project will take off.
Mind you it's impressive what's been accomplished with a tiny team, however koffice is in no way usable, I know, I've tried. It's pretty but it doesn't do the job.
"In this interview with the KOffice development team it is revealed that only about 4-6 people are working on the suite of applications.
Yes, well I know exactly why that is. A few years ago I decided to hack kmail a little, until I found I had to build pretty much all of kde from source to do it. As opposed to installing the -devel headers as you would for more developer-friendly applications, then just untarring,./configure, make. This stopped me, I see no reason why it wouldn't stop lots of folks.
Casual hacking is the way to get started on a project, it's wrong to require a whole huge cvs import and hours of mucking around with scripts trying to get the thing to build. Once you start with the casual hacking and submit a few patches, it's much easier to justify the effort to get in all the way and sync up to cvs.
If the koffice team wants more helpers, then they should put the effort into making it easier to get started. That means writing some scripts to pull tarballs out of cvs and hacking together some autoconf stuff. This effort will for sure pay off. People will start sending patches, and after a while some of them will get involved in a more hardcore way.
Look, why are the 1,000's of people hacking the Linux kernel tree? Because you can just grab the tarball and build it, no fuss no muss. Only super-hardcore developers or paid employees are going to get into a project by syncing to the cvs from the word go.
David, bless him, didn't get this 3 years ago, I hope he'll think about it now.
And their draktools now have an option to display what the GUI tools are doing to which log files.
Wow. That's exactly what I've always wanted in a point-n-drool configuration interface. It's at the same time a quick start and a learning tool, maybe you could think of it as documentation too.
I find in the long run I always gravitate to the command line given a choice, simply because it's faster and can be automated. But when I'm encountering a new subsystem for the first time, I like a little handholding. Traditionally that's come from other, more experienced admins, but this kind of gui/logging tool will be a perfect substitute for that kind of knowledge sharing in most common case. It means the guru card only needs to be played to get the deepest, darkest secrets.
A case in point is the recent Slasdot story [slashdot.org] concerning the development of sites only in Flash (no HTML content at all). This breaks lots of things you probably take for granted, like search engines. You're saying this is a good thing because its obviously what bussiness wants? I'm not convinced.
Right, and it breaks cut n paste, and I can't turn off the animations. For starters, there's a lot more wrong than that.
I appeciate the graphics and the efficiency, but I resent the loss of control and flexibility. I guess the problem mainly lies in the the players. I don't see why search engines can't dive inside the flash files and index the text, as with pdf's.
Oh, and having Shockwave continue to control the format is a bad idea for the public. I suppose if that doesn't get resolved we'll see a truly open knockoff pretty soon. SVG is a step in the right direction, if the patent issues get worked out.
it truly would be nice to have an AOL client for Linux. But they really only have two options: 1. support ONLY UNMODIFIED RPM-ONLY REDHAT BOXES (or xxx other distribution) 2. build an all-in-wonder static library that has the dialer, gecko, vpn client, and everything all built-in.
3. Open the specs and let us build a client for them.
Not that I'd use it personally, but other folks might.
Many of the comments on this thread might be summarized as follows: why is Microsoft doing this? The answer is that we really want the ECMA standard to succeed (and that includes success for non-Microsoft CLI implementations!) and we also want to seed the use of the CLI over the long haul.
That's bullshit. If you wanted it to succeed you'd release it under a free license that allows commercial exploitation. There's more to this strategem than you'd like to suggest.
Re:I hope MPEG-4 fails
on
More on MPEG4
·
· Score: 2
I agree with Ben Waggoner...
While your post isn't a troll, it's worth noting that Ben Waggoner is an astroturfer:
Inside Windows Media, Microsoft, QUE, 1999
Ben Waggoner, Media 100 (formerly Terran),
conference presentations and articles
It's entirely disreputable of him not to state his affiliation, and incredibly ignorant of Salon not to do this simple check, or ask him.
Computer text is usually rendered onto a solid color
Usually. What about when it isn't?
and displayed on a high-quality, high-bandwidth device. That has almost nothing to do with rendering text for overlay onto a pictorial background and display on a low-pass, noisy device like broadcast television. Rendering text for GUIs the way you render it for television would be like slapping people in the face to get their attention and just would drive them crazy.
Yes, they wouldn't be able to deal with the fact the the text doesn't look butt-ugly as usual.
Anti-aliasing for computer displays is overrated anyway. Whether it helps or hurts readability depends on the font and font size, and on high resolution displays it is pointless. Printed matter isn't anti-aliased either, and printed matter is the gold standard for good looking text.
Bzzzt. Printing is analog, it's naturally anti-aliased.
So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing. Anything else is a kludge
Think about anti-aliased text on a 150 dpi monitor. Or, no, first find out what anti-aliasing is.
But I'm curious. --Were the accounts you were swapping money between two Paypal accounts, or were you trying to move money from a Paypal account to a regular bank account?
It was between two Paypal accounts. You know the really nasty thing? First they froze the destination account, then waited long enough for my bank to transfer my money into the source account, *then* froze it there. Ensuring they had something to collect interest on while they gave me the runaround. How do you like that for evil?
(My company is getting into Paypal regardless of my repeated cautions.)
Show them my post.
Paypal currently has several thousand dollars of mine tied under a 'restriction', when all I tried to do was transfer the money from my account to one of my familly members. This worked perfectly with a small amount of money, but the larger amount has caused me extreme grief. Paypal has had the money for a week now, and they refuse to return it to the original account (mine), even though I have jumped through all the hoops they set out for me - some of them several times. They have sent me on a wild goose chase of busy fax machines and even busier phone numbers, so that I can 'appeal' their 'restriction' of my funds. They requested documentation be sent by fax, to prove I am the owner of the account, and I did - three times. Dozens of emails went unanswered. Finally one email arrived informing me that my case would be forwarded to the 'appeals' department within 48 hours. No word on how long it would stay there. In the meantime, Paypal has my money, and is collecting interest on it.
I believe that Paypal is intentionally going slow, and that much of the procedure they have imposed on me is merely a pretext to allow them to keep my money for a longer period, and collect interest on it. This is done under the guise of fraud protection, but I ask you, what harm would there ever be in returning money to its original owner, even if there was some suspicion that the money was not in fact transferred by the original owner. (In my case of course it was.) They collect the profits while I wonder if I will ever see my money again. It does not help to know that Paypal is not regulated as a bank, in fact, not regulated at all.
Will Paypal compensate me for my time and expense in retrieving my money? Will they ever give me my money back? You tell me. I do not know. At this point, I would like to sue Paypal, if I could figure out how to do it. Unfortunately, I am not a U.S. citizen, and so I can not join one of the class action suits currently in progress against Paypal.
I have only one more thing to say at this point: do not use Paypal.
"I know this will start a heated debate, but if my tax dollars are paying for something, I want it issused so that some value comes back, not just a welfare-like giveaway."
;-)
Who cares what you want?
Brilliant, that's billg's main argument too!
If *MY* tax dollars are paying for something I damn well want to be able to use the fruits of that work any way I please - including in ways which are NOT GPL compatible.
Right. So if your tax dollars pay for a park, you want to be able to use it any way you want, including putting up a fence around a piece of it, and running strangers off your new-found property.
I just pointed out the lunacy that GPL'd code leads to interoperability. It doesn't because it's unusable by developers who use alternative licenses.
Compatibility and interoperability are best achieved by releasing code that can be used by the widest audience possible. If compatability is your goal you should try to eliminate any barriers at all that exist between the shared code and the developers who can use it.
The GPL strives to do lots of things but compatability and interoperability aren't on that list.
Sorry, Linux itself is the classic counterexample to your argument. Just because of the sheer number of programmers working on it, Linux has come to overshadow all other forms of Unix, and to impose on them a level of interoperability that has never existed before. That is, everybody who wants their Unix variant to survive needs to be able to run programs written for Linux, and thus needs to support the Linux system calls accurately and completely. One by one, all the traditional Unixen are fall into line, or they die.
Poof! Interoperability, by sheer force of will of those programmers who are so strongly motivated to work under the GPL (and thus prevent their own intellectual property from being taken away from them and the public to whom they beqeathed it) that they built Linux into the best operating system ever.
This scenario is likely to be played out over and over again, wherever there is fragmentation of standards due to proprietary interests. After all, it was proprietary interests that caused Unix to fragment in the first place. This evil has now been undone.
For some reason, I can't help but think amd's ceo has a valid point here.
Would (almost) every home have a pc if microsoft didn't exist?
Yes, certainly. The day the IBM PC came out, thousands of competent professions knew exactly what they were looking at: the first personal computer capable of doing the things that were at the time being done on minicomputers. We jumped on it immediately, and believe me, Microsoft was never an essential part of that. If msdos never existed, we would have quickly produced something else - probably better - and effected the PC revolution without Microsoft. Microsoft was never essential at all, in fact they did more to slow down development than most people realize. Perhaps somebody can explain to me how Microsoft's macro assembler was delayed for a number of months, and no assembler released by IBM in that time, in spite of the fact that it obviously existed, and had been used to build Microsoft's own compiler offerings? Microsoft came out of that with a comfortable lead over all other tool builders and never looked back.
By my reckoning, Microsoft has already held back the evolution of software by 10 years over the last 20, and with their current level of suppression of independent effort, that pattern is likely to continue.
I'll assume that to mean that previously, you've bought AMD rather than Intel for political reasons. And I'll also assume that to mean that in the future you won't buy AMD because they've sunken down, politically, to an Intel-like level (although I wouldn't go that far, myself).
If so, however, why wouldn't you buy AMD, if they are (at the time of purchase) producing the best chips?
In my case it's simple: I feel betrayed. Up till now I've been willing to overlook AMD's shortcomings and dwell on the advantages. Once burned, twice shy. AMD has demonstrated its willingnes to toss us to the wolves, so...
I think that given the XBOX has has questionable market acceptance, that the damage done in supporting microsoft is far worse than the potential gain in chip sales through what is still a vapor product (and seeks to eliminate Nvidia for some odd reason in favor of ATI).
Oh yes, they just lost me. Up till now I'd been planning to design twin Athlons into a server product, in spite of the poor heat situation. Now it's AMD out, Intel in, thanks a lot for helping me make that decision AMD.
If political considerations are more important to you, consider writing your own open source SVG authoring tool -- for Linux only, of course -- and nuts to your users.
You are frothing. Check out sodipodi.
As you can see here.
Even though the W3C has backed away from the proposal to include RAND-licenced patented material in W3C standards, the SVG standard went to 1.0 under the assumption that the public would accept RAND-licensing for web standards, and so SVG incorporates a number of RAND-liceneced patents, specifically from IBM Kodak and Quark. No doubt this situation is going to be resolved, especially if people don't forget it still needs to be resolved. To remind the W3C and the companies involved that this situation is still unresolved, you can comment on this list, subscribe here.
And oh by the way, is IBM's roll in this particular little minidrama hypocritical, given their support for and reliance upon Linux and other open source projects? You bet it is, and that's because IBM has lots of little parts, not all of which are headed in the same direction, e.g., some are run by the legal department or managers who still don't get it.
I'm not 100% sure, but I've heard Microsoft has a large interest in Best Buy, or a controlling interest. Does anyone have accurate data on this?
I did not fail to notice the MSN posters hanging from the roof the last time I was there.
It might even be something that happens just as often on with the combination patch as with the low-latency patch, except the combo got lucky.
If you'd actually read the article you'd know that this can't happen with the preempt patch + low-latency, not unless a spinlock gets jammed, then you have much worse problems. The preempt patch takes care of scheduling events that occur during normal kernel execution (and it does this much more reliably than the low latency patch) but since preemption isn't allowed while spinlocks are held, it can't do anything about latency due to spinlocks. This explains the apparently worse performance of the preempt patch - you're just seeing the spinlock latency there.
The low latency patch breaks up the spinlocks with explicit scheduling points, which is pretty much the only approach possible without really major kernel surgery. That's why the combination works so well. In fact, the parts of the low latency patch that aren't connected with breaking up spinlocks aren't doing anything useful and should be omitted. The worst-case performance won't change.
Yahoo has done well by me. The mail service has been really good about always being there, *never* losing a mail, service interruptions very rare, and as I recall, being due to DoS attacks more often than not.
Even though I don't need the account any more as an 'on the road' kind of thing, since I got to the state of cluefulness to be able to deal with mail without the help of an ISP, I just don't mind making a small investment to maintain the service. In my opinion, Yahoo is one of the less evil companies around and so, here's my nickel.
Another factor in this is... I don't mind sending mail with Yahoo branding, it's not nearly as embarrasing as say, showing up in somebody's mailbox wearing Hotmail noseglasses.
I never used the scripts, I just followed the instructions. Pretty easy, although it did take a long while to download and build. Never used cvs before then.
;-) You can always get help on mailing lists or from google if you have trouble.
./configure
http://www.kde.org/kde2-and-kde3.html
http://www.kde.org/install-source.html
Helped also. Persevere and it will pay off. You learn a bit about cvs, about writing scripts and you get latest KDE which is always better than releases
Sorry, this just isn't as easy or fast as:
1) install the headers
2) grab the tarball
3) unpack the tarball
4)
5) make
And puts way less load on your disk. Think about it: if it was so easy, then why are there only 4-6 active contributors?
I see a some people making the mistake of thinking that cvs and tarballs are mutually exclusive. They're not. Every so often, preferably at some point release a core developer runs a script to pull tarballs for each app out of the tree. If this isn't possible then the project framework is seriously borked anyway.
Then people who want to contribute have the choice of sending patches against the tarballs or joining the hardcore team and syncing up with cvs. Which isn't as good an idea as it sounds, it's not particularly easy to do productive work when the whole system is changing all the time, and maybe you're not a core developer so you don't know what's happening, why or when. Much easier to work with a stable point release, then when you have something you like send the patch to somebody with cvs access. If they blackhole it, find another project, if they accept it, you're on your way, one day you'll have cvs.
It's a big mistake to make every possible contributor go through the same pain that a core developer has to, to sync up with the bleeding edge.
Funny, I switched from RedHat to FreeBSD due to a seemingly endless line of RPM dependancy issues, config files that seem to defy all logic, and a directory structure that feels like your totally lost in a video game maze.
It sounds like you really needed to try Debian.
http://www.kde.org/anoncvs.html
There are scripts linked to at the bottom of the page that do everything for you as well (one is in webcvs.kde.org).
I know about that page and those scripts. It still takes hours, if you don't believe me try it. (Make sure you're a newbie to kde building first, otherwise your data is suspect.)
Tarballs generally unpack and install in a few minutes and the compile generally works the first time. I'm sorry, but cvs + futzing with scripts that are broken half the time is just not like that.
KOffice is a set of components, not a monolith. KDE uses a component based development model. Thus each of these "applications", kword, kspread, kpresenter, etc, are kparts. You can work on one and never even see the source for the rest. They are just released together as a bundle by the KDE project.
That's exactly the problem. Break each application out as a tarball instead of requiring people to deal with the whole bundle and the project will take off.
Mind you it's impressive what's been accomplished with a tiny team, however koffice is in no way usable, I know, I've tried. It's pretty but it doesn't do the job.
"In this interview with the KOffice development team it is revealed that only about 4-6 people are working on the suite of applications.
./configure, make. This stopped me, I see no reason why it wouldn't stop lots of folks.
Yes, well I know exactly why that is. A few years ago I decided to hack kmail a little, until I found I had to build pretty much all of kde from source to do it. As opposed to installing the -devel headers as you would for more developer-friendly applications, then just untarring,
Casual hacking is the way to get started on a project, it's wrong to require a whole huge cvs import and hours of mucking around with scripts trying to get the thing to build. Once you start with the casual hacking and submit a few patches, it's much easier to justify the effort to get in all the way and sync up to cvs.
If the koffice team wants more helpers, then they should put the effort into making it easier to get started. That means writing some scripts to pull tarballs out of cvs and hacking together some autoconf stuff. This effort will for sure pay off. People will start sending patches, and after a while some of them will get involved in a more hardcore way.
Look, why are the 1,000's of people hacking the Linux kernel tree? Because you can just grab the tarball and build it, no fuss no muss. Only super-hardcore developers or paid employees are going to get into a project by syncing to the cvs from the word go.
David, bless him, didn't get this 3 years ago, I hope he'll think about it now.
And their draktools now have an option to display what the GUI tools are doing to which log files.
Wow. That's exactly what I've always wanted in a point-n-drool configuration interface. It's at the same time a quick start and a learning tool, maybe you could think of it as documentation too.
I find in the long run I always gravitate to the command line given a choice, simply because it's faster and can be automated. But when I'm encountering a new subsystem for the first time, I like a little handholding. Traditionally that's come from other, more experienced admins, but this kind of gui/logging tool will be a perfect substitute for that kind of knowledge sharing in most common case. It means the guru card only needs to be played to get the deepest, darkest secrets.
A case in point is the recent Slasdot story [slashdot.org] concerning the development of sites only in Flash (no HTML content at all). This breaks lots of things you probably take for granted, like search engines. You're saying this is a good thing because its obviously what bussiness wants? I'm not convinced.
Right, and it breaks cut n paste, and I can't turn off the animations. For starters, there's a lot more wrong than that.
I appeciate the graphics and the efficiency, but I resent the loss of control and flexibility. I guess the problem mainly lies in the the players. I don't see why search engines can't dive inside the flash files and index the text, as with pdf's.
Oh, and having Shockwave continue to control the format is a bad idea for the public. I suppose if that doesn't get resolved we'll see a truly open knockoff pretty soon. SVG is a step in the right direction, if the patent issues get worked out.
it truly would be nice to have an AOL client for Linux. But they really only have two options:
1. support ONLY UNMODIFIED RPM-ONLY REDHAT BOXES (or xxx other distribution)
2. build an all-in-wonder static library that has the dialer, gecko, vpn client, and everything all built-in.
3. Open the specs and let us build a client for them.
Not that I'd use it personally, but other folks might.
In fact, somebody please go and mod up all oxfletch's posts on this article, he's Martin Bligh, the guy who did this.
1. 2.4.18, and I also told you what patches I was using (though some of them won't be published until next week).
2. OK, I just posted the config file. http://lse.sourceforge.net/numa/config.mem
3. I did five kernel compiles in a row (though I omitted to mention that).
Hi Martin!
--
Daniel
Many of the comments on this thread might be summarized as follows: why is Microsoft doing this? The answer is that we really want the ECMA standard to succeed (and that includes success for non-Microsoft CLI implementations!) and we also want to seed the use of the CLI over the long haul.
That's bullshit. If you wanted it to succeed you'd release it under a free license that allows commercial exploitation. There's more to this strategem than you'd like to suggest.
I agree with Ben Waggoner...
While your post isn't a troll, it's worth noting that Ben Waggoner is an astroturfer:
Inside Windows Media, Microsoft, QUE, 1999
Ben Waggoner, Media 100 (formerly Terran),
conference presentations and articles
It's entirely disreputable of him not to state his affiliation, and incredibly ignorant of Salon not to do this simple check, or ask him.
Computer text is usually rendered onto a solid color
Usually. What about when it isn't?
and displayed on a high-quality, high-bandwidth device. That has almost nothing to do with rendering text for overlay onto a pictorial background and display on a low-pass, noisy device like broadcast television. Rendering text for GUIs the way you render it for television would be like slapping people in the face to get their attention and just would drive them crazy.
Yes, they wouldn't be able to deal with the fact the the text doesn't look butt-ugly as usual.
Anti-aliasing for computer displays is overrated anyway. Whether it helps or hurts readability depends on the font and font size, and on high resolution displays it is pointless. Printed matter isn't anti-aliased either, and printed matter is the gold standard for good looking text.
Bzzzt. Printing is analog, it's naturally anti-aliased.
So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing. Anything else is a kludge
Think about anti-aliased text on a 150 dpi monitor. Or, no, first find out what anti-aliasing is.