Buddhism is not purely defined by what Buddha said. You cannot discount thousands of years of teaching and tradition as having "no impact".
The plain and simple fact is that the vast majority of Buddhists in the world today believe in spiritual things. Good luck convincing them that the religion they have followed all their lives is really a secular philosophy.
Is there a benefit to running a bloated and buggy text editor?
What you call "bloat", we call "features".
What you call "bugs", we also call "features".;)
Re:99% of the answers are going to be Eclipse
on
What Free IDE Do You Use?
·
· Score: 3, Informative
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
I've worked on programs much larger than 10kloc in both Emacs and Netbeaans. I gave up on Netbeans and went back to Emacs because I was just so much more productive there -- even when working in (yuck) Java.
It's pretty modern these days, too. It has intelligent autocomplete, it has a class browser, it has jump-to-definition, it will tell me the type of the variable under the cursor, it does code folding, it does source-level debugging... in fact, pretty much the only thing present in "modern" IDEs that Emacs doesn't have is a point-and-drool GUI designer, and that's fine by me because I don't design GUIs.
And it is far, far better at actually editing text than any IDE editor I've ever seen.
I've experienced Netbeans taking up to five minutes to load, and that's on Sun's own current workstation hardware. If that's not bloated, then what is?
Indeed. There's little point trying to compete with C on speed alone. Your C version will also almost certainly use less memory.
The real point, however, is that your code would be written in a low-level language and his is written in a high-level language. In theory, this means that he will be able to add new features more easily than you can, and he will be able to use one language for everything, instead of one for the server and another for scripting. (I assume you will agree that C is not a great choice for web pages themselves, even with FastCGI?)
Actually, it was also a public holiday in the UK, at least. (Google suggests it was in Lebanon and Ghana too, but those are less significant sources of Slashdot traffic.)
Funny how an attempt to paint someone else as US-centric can serve only to show up your own ignorance of what's going on outside your own country...
It's bad either way. Even if it is true that they have something that genuinely can only be made to work with Windows as of today (and they genuinely cannot meet said Windows requirement in any way other than having Windows on all desktops), they should still open the bidding process and allow Linux vendors to quote them a price that includes fixing the problem in Linux.
It might still work out cheaper than going with Windows, and if it doesn't, then they can still go with Windows, secure in the knowledge that there has been a fair and open bidding process to justify their decision.
As for the monopoly argument, I don't see a problem with the term. If the Swiss government is automatically granting business to Microsoft without allowing any competitors to bid, then the Swiss government is indeed effectively granting Microsoft a monopoly. The market in question is a fairly small one, and the existence of the monopoly is the fault of the Swiss government rather than of Microsoft, but it appears to exist nonetheless.
Doing it the way you suggest is tempting, but that way madness lies. It's easy to hack in a feature, and it's usually not too hard to get it working. The difficult part is making it modular and maintainable.
Implementing a DIB engine any old how would get us a DIB engine, but it wouldn't necessarily be a net gain if in the process it also made it a hundred times harder to implement some other core GDI functionality, or if it was implemented in so careless a way that it started breaking unexpectedly when completely unrelated code was changed!
I don't know the details of this case. I have not read any patches or IRC logs and I don't know what is involved in implementing a DIB engine. All I'm saying is that it is very reasonable for a large and complex project to reject patches on the grounds that their architecture isn't satisfactory. If that is the case here, then the Wine project might be behaving sensibly. Certainly it seems they could be more communicative, but that doesn't automatically mean they're wrong.
Desktop integration - applications running in wine will open a normal window along the rest of my desktop applications. So you can cut/paste between them, and put them in a beside each other and so on. With a vm, the vm take over the entire screen.
This is not accurate. With software like VirtualBox, the VM only takes up as much of the screen as you tell it to, and you can cut/paste between applications within the VM and those outside it. Run your one Windows application maximised, and it's comparable to Wine (slower and less convenient, but much more compatible).
VirtualBox also has a mode that tries to make it look like the Windows applications are running normally on your X desktop, but it doesn't work very well yet (all Windows applications are stuck together on a single layer).
In the case of Sun's patch it sounds like "not pretty" means he either did something like put in C++ style comments or didn't match the coding standard on the file he was editing.
In which case, why was the reason for rejection not given as the concrete and rectifiable "wrong coding style"?
As it stands, "not pretty" could refer to just about anything. When I read that post I assumed it was referring to algorithmic elegance, not coding style. And that's the problem: the critique is so vague as to be utterly worthless.
That question could be applied to a lot of things, and not just the whole KDE4 mess. Xfce 2.6 should never have made it into Jaunty, with no menu editor and vertical panels totally broken.
I use Linux because, with a bit of hacking and some command-line wizardry, I can turn it into a better OS for my purposes than anything else. But I don't recommend it to anyone less geeky than myself. There's simply no way it's going to be a suitable platform for the average user, as long as upgrades routinely lead to major regressions.
Honestly, the single most productive thing you could do to ensure the rapid uptake of open standards would be to make openoffice.org an amazing product. Put all of your time and effort into making it clearly superior, and at that point everyone will use an ODF by default.
(a) You're making the common mistake of conflating ODF with OOo. The two are completely separate entities. People who advocate the use of ODF are not necessarily OOo fans; they may prefer Abiword, KOffice, or even Microsoft Office. The whole point of open standards is that it shouldn't matter what software you use.
(b) Even if you take your goal to be the promotion of OOo (a particular software product) rather than ODF (a document standard), then it's naive to think that all you have to do is make a product that's better than MS Office. The sad truth is that no matter how good your product is, most people will be reluctant to switch to it. People hate change. The product would need not only to be better, but to be about 10 times better. And then you would need to communicate that fact, in the face of the best marketing that one of the world's richest companies can buy. Not an easy task.
But if you can get open standards adopted, then there's no longer any reason to care about increasing OOo market share, because it won't matter what software people use: you'll still be able to read their documents and they'll still be able to read yours.
Point taken, but then large corporations can define which version of which browser or JVM is standard and installed on their users' machines, n'est-ce pas?
They can, yes. And then suddenly it's 2009, and that critical web app that only works in IE5.5 with JRE 1.1 is starting to become a bit of a problem.
Normal people are tolerant of others. Nerds use knowledge as a weapon. I suppose it's a coping mechanism or some such thing.
Here's a little experiment for you to try to test your hypothesis.
Go into your local bar when there's a big sports event on. Find the least nerdy-looking guy you can see. Go up to him and start talking about the sport, but use random sporty terms instead of the proper names for things. "Man, I love baseball, specially when the quarterback gets a hole in one!"
and get on with their lives. And all will be well right up until the "c" parameter turns out to include a side effect, at which point all hell will break loose.
Really, Microsoft should know better. If you try to make your API foolproof, someone will just invent a better fool.
Unfortunately, most programmers view solving concurrency with pure functional programming in much the same light that the average guy on the street views solving differential equations with Fourier transforms. You may well be applying a technique that is well understood in academic circles, but from Joe Average's perspective, the solution is even harder to grasp than the problem was.
You might argue that any programmer worthy of the name should be able to write side-effect-free code. I happen to agree with that position. But Sturgeon's Law tells us that most programmers aren't worthy of the name, and there's no simple solution to that. You can't just fire them all, tempting though the idea may sound.
better yet, there is no need to check extensions or metadata, just do a magic test (file command from the CLI) to know the content type of the file.
Great. So instead of just looking at the filename, you propose that my OS should distinguish between OpenOffice documents and Java applications by decompressing a ZIP archive and examining the contents?
"Okay, the XML files in this archive don't validate against the ODF schema. Let's try OOXML..."
And it gets really fun when it comes to text files. Hmm, should I display this source code with the Java icon, the C# icon, or the C++ icon? Let me just compile it to find out, because that's so much more reliable than checking the last few characters of the filename!
Ah, hang on a second, it looks like that file's on a remote filesystem anyway. Hang on, I'll display the icons as soon as the robot on the other end has retrieved the relevant tapes and started restoring their contents.
Who goes to Cheapscum's Ratburgers when there's a Burger King next door?
That would be like using PHP when Perl, Python, and Ruby are all just as quick, just as easy, far better designed, and far more conducive to writing robust and maintainable code...
my utter lack of belief that they would honestly report any problems they found with the system to the public
Why? We aren't talking about something like disk encryption where the government might supposedly want to have a secret backdoor they could use to snoop on your data.* We're talking about smart cards that are going to be used by the government itself to provide security to that government's own premises. What motive would they have for concealing problems?
Even supposing they found cryptographic weaknesses and decided not to publish details of them, you would expect them to have fixed any such weaknesses before rolling out the system. Their job is to secure their own buildings. They're hardly going to deliberately choose a broken system to do that - there are limits even to government stupidity.
* Not that there's any reason to believe governments do much of this kind of thing. AES, for example, has withstood years of intensive scrutiny without so much as a hint of a backdoor.
Such a search engine would, by definition, not be decent.
He said an engine that supports regular expressions. Not one that doesn't provide anything else. Pray elucidate: how, exactly, does adding a powerful and useful feature make something worse "by definition"?
The syntax of Perl regex is very powerful but virtually incomprehensible to most people.
The same is true of English, and yet many people seem to think that asking questions in English would be the perfect search interface...
The search engine would also be very slow.
You mean you don't know how to make it fast.
Realistically, it would be reasonable to require regular search terms as well, and use the regex support to filter results produced by the existing Google-like search. This would probably be perfectly feasible. Particularly given that most people would not use the regex feature.
(That in itself is a fair reason not to invest money developing such a feature. But that's a totally different issue, utterly unrelated to the utility or feasibility of regex searches.)
5 *million* lines of Mathematica? How many code monkeys does he have working for him?
Have you forgotten who we're talking about here? Wolfram is a hype machine. Even the Mathematica documentation reads like advertising. I'm almost surprised that the program itself doesn't pop up messages every few seconds saying "Congratulations, you're still using Wolfram Mathmatica(r), the most powerful and intuitive computational tool in this or any other universe!"
Here is a program you can use to recreate an artist's impression of the Wolfram Alpha source code:
#!/bin/sh yes 'Print["Just how awesome is Wolfram Alpha? THIS awesome!!!!"]' head -5000000 > alpha.ma
You are wrong (assuming you're referring to US law). A "right to make archival copies" does exist, but it applies only to computer software, not to digital media. (Source)
Their homegrown ERP systems were even *worse*, if you can imagine worse..
Imagine? I don't need to imagine. I've used them.
I have never in all my life seen a worse user interface. It makes the UNIX command line look intuitive. (In fact, I replaced the part of it I had to use with a screen-scraping Perl script, which was a vast improvement.)
Excellent. More hilarous deluded rants to enjoy, and more righteous thrashing from courts that understand what the US constitution means.
The people in power have repeatedly shown that they don't take fanatics like Thompson any more seriously than we do. So let him rant. If anything, he helps the cause of free speech, by discrediting the opposition.;)
Buddhism is not purely defined by what Buddha said. You cannot discount thousands of years of teaching and tradition as having "no impact".
The plain and simple fact is that the vast majority of Buddhists in the world today believe in spiritual things. Good luck convincing them that the religion they have followed all their lives is really a secular philosophy.
What you call "bloat", we call "features".
What you call "bugs", we also call "features". ;)
I've worked on programs much larger than 10kloc in both Emacs and Netbeaans. I gave up on Netbeans and went back to Emacs because I was just so much more productive there -- even when working in (yuck) Java.
It's pretty modern these days, too. It has intelligent autocomplete, it has a class browser, it has jump-to-definition, it will tell me the type of the variable under the cursor, it does code folding, it does source-level debugging ... in fact, pretty much the only thing present in "modern" IDEs that Emacs doesn't have is a point-and-drool GUI designer, and that's fine by me because I don't design GUIs.
And it is far, far better at actually editing text than any IDE editor I've ever seen.
Also, it reads mail. :p
I've experienced Netbeans taking up to five minutes to load, and that's on Sun's own current workstation hardware. If that's not bloated, then what is?
Indeed. There's little point trying to compete with C on speed alone. Your C version will also almost certainly use less memory.
The real point, however, is that your code would be written in a low-level language and his is written in a high-level language. In theory, this means that he will be able to add new features more easily than you can, and he will be able to use one language for everything, instead of one for the server and another for scripting. (I assume you will agree that C is not a great choice for web pages themselves, even with FastCGI?)
Actually, it was also a public holiday in the UK, at least. (Google suggests it was in Lebanon and Ghana too, but those are less significant sources of Slashdot traffic.)
Funny how an attempt to paint someone else as US-centric can serve only to show up your own ignorance of what's going on outside your own country ...
It's bad either way. Even if it is true that they have something that genuinely can only be made to work with Windows as of today (and they genuinely cannot meet said Windows requirement in any way other than having Windows on all desktops), they should still open the bidding process and allow Linux vendors to quote them a price that includes fixing the problem in Linux.
It might still work out cheaper than going with Windows, and if it doesn't, then they can still go with Windows, secure in the knowledge that there has been a fair and open bidding process to justify their decision.
As for the monopoly argument, I don't see a problem with the term. If the Swiss government is automatically granting business to Microsoft without allowing any competitors to bid, then the Swiss government is indeed effectively granting Microsoft a monopoly. The market in question is a fairly small one, and the existence of the monopoly is the fault of the Swiss government rather than of Microsoft, but it appears to exist nonetheless.
Doing it the way you suggest is tempting, but that way madness lies. It's easy to hack in a feature, and it's usually not too hard to get it working. The difficult part is making it modular and maintainable.
Implementing a DIB engine any old how would get us a DIB engine, but it wouldn't necessarily be a net gain if in the process it also made it a hundred times harder to implement some other core GDI functionality, or if it was implemented in so careless a way that it started breaking unexpectedly when completely unrelated code was changed!
I don't know the details of this case. I have not read any patches or IRC logs and I don't know what is involved in implementing a DIB engine. All I'm saying is that it is very reasonable for a large and complex project to reject patches on the grounds that their architecture isn't satisfactory. If that is the case here, then the Wine project might be behaving sensibly. Certainly it seems they could be more communicative, but that doesn't automatically mean they're wrong.
This is not accurate. With software like VirtualBox, the VM only takes up as much of the screen as you tell it to, and you can cut/paste between applications within the VM and those outside it. Run your one Windows application maximised, and it's comparable to Wine (slower and less convenient, but much more compatible).
VirtualBox also has a mode that tries to make it look like the Windows applications are running normally on your X desktop, but it doesn't work very well yet (all Windows applications are stuck together on a single layer).
In which case, why was the reason for rejection not given as the concrete and rectifiable "wrong coding style"?
As it stands, "not pretty" could refer to just about anything. When I read that post I assumed it was referring to algorithmic elegance, not coding style. And that's the problem: the critique is so vague as to be utterly worthless.
I meant Xfce 4.6, of course.
That question could be applied to a lot of things, and not just the whole KDE4 mess. Xfce 2.6 should never have made it into Jaunty, with no menu editor and vertical panels totally broken.
I use Linux because, with a bit of hacking and some command-line wizardry, I can turn it into a better OS for my purposes than anything else. But I don't recommend it to anyone less geeky than myself. There's simply no way it's going to be a suitable platform for the average user, as long as upgrades routinely lead to major regressions.
(a) You're making the common mistake of conflating ODF with OOo. The two are completely separate entities. People who advocate the use of ODF are not necessarily OOo fans; they may prefer Abiword, KOffice, or even Microsoft Office. The whole point of open standards is that it shouldn't matter what software you use.
(b) Even if you take your goal to be the promotion of OOo (a particular software product) rather than ODF (a document standard), then it's naive to think that all you have to do is make a product that's better than MS Office. The sad truth is that no matter how good your product is, most people will be reluctant to switch to it. People hate change. The product would need not only to be better, but to be about 10 times better. And then you would need to communicate that fact, in the face of the best marketing that one of the world's richest companies can buy. Not an easy task.
But if you can get open standards adopted, then there's no longer any reason to care about increasing OOo market share, because it won't matter what software people use: you'll still be able to read their documents and they'll still be able to read yours.
They can, yes. And then suddenly it's 2009, and that critical web app that only works in IE5.5 with JRE 1.1 is starting to become a bit of a problem.
Here's a little experiment for you to try to test your hypothesis.
Go into your local bar when there's a big sports event on. Find the least nerdy-looking guy you can see. Go up to him and start talking about the sport, but use random sporty terms instead of the proper names for things. "Man, I love baseball, specially when the quarterback gets a hole in one!"
See just how much tolerance you get.
No, they'll just write
and get on with their lives. And all will be well right up until the "c" parameter turns out to include a side effect, at which point all hell will break loose.
Really, Microsoft should know better. If you try to make your API foolproof, someone will just invent a better fool.
Unfortunately, most programmers view solving concurrency with pure functional programming in much the same light that the average guy on the street views solving differential equations with Fourier transforms. You may well be applying a technique that is well understood in academic circles, but from Joe Average's perspective, the solution is even harder to grasp than the problem was.
You might argue that any programmer worthy of the name should be able to write side-effect-free code. I happen to agree with that position. But Sturgeon's Law tells us that most programmers aren't worthy of the name, and there's no simple solution to that. You can't just fire them all, tempting though the idea may sound.
Great. So instead of just looking at the filename, you propose that my OS should distinguish between OpenOffice documents and Java applications by decompressing a ZIP archive and examining the contents?
"Okay, the XML files in this archive don't validate against the ODF schema. Let's try OOXML..."
And it gets really fun when it comes to text files. Hmm, should I display this source code with the Java icon, the C# icon, or the C++ icon? Let me just compile it to find out, because that's so much more reliable than checking the last few characters of the filename!
Ah, hang on a second, it looks like that file's on a remote filesystem anyway. Hang on, I'll display the icons as soon as the robot on the other end has retrieved the relevant tapes and started restoring their contents.
Who goes to Cheapscum's Ratburgers when there's a Burger King next door?
That would be like using PHP when Perl, Python, and Ruby are all just as quick, just as easy, far better designed, and far more conducive to writing robust and maintainable code...
Why? We aren't talking about something like disk encryption where the government might supposedly want to have a secret backdoor they could use to snoop on your data.* We're talking about smart cards that are going to be used by the government itself to provide security to that government's own premises. What motive would they have for concealing problems?
Even supposing they found cryptographic weaknesses and decided not to publish details of them, you would expect them to have fixed any such weaknesses before rolling out the system. Their job is to secure their own buildings. They're hardly going to deliberately choose a broken system to do that - there are limits even to government stupidity.
* Not that there's any reason to believe governments do much of this kind of thing. AES, for example, has withstood years of intensive scrutiny without so much as a hint of a backdoor.
He said an engine that supports regular expressions. Not one that doesn't provide anything else. Pray elucidate: how, exactly, does adding a powerful and useful feature make something worse "by definition"?
The same is true of English, and yet many people seem to think that asking questions in English would be the perfect search interface ...
You mean you don't know how to make it fast.
Realistically, it would be reasonable to require regular search terms as well, and use the regex support to filter results produced by the existing Google-like search. This would probably be perfectly feasible. Particularly given that most people would not use the regex feature.
(That in itself is a fair reason not to invest money developing such a feature. But that's a totally different issue, utterly unrelated to the utility or feasibility of regex searches.)
Have you forgotten who we're talking about here? Wolfram is a hype machine. Even the Mathematica documentation reads like advertising. I'm almost surprised that the program itself doesn't pop up messages every few seconds saying "Congratulations, you're still using Wolfram Mathmatica(r), the most powerful and intuitive computational tool in this or any other universe!"
Here is a program you can use to recreate an artist's impression of the Wolfram Alpha source code:
You are wrong (assuming you're referring to US law). A "right to make archival copies" does exist, but it applies only to computer software, not to digital media. (Source)
Imagine? I don't need to imagine. I've used them.
I have never in all my life seen a worse user interface. It makes the UNIX command line look intuitive. (In fact, I replaced the part of it I had to use with a screen-scraping Perl script, which was a vast improvement.)
Excellent. More hilarous deluded rants to enjoy, and more righteous thrashing from courts that understand what the US constitution means.
The people in power have repeatedly shown that they don't take fanatics like Thompson any more seriously than we do. So let him rant. If anything, he helps the cause of free speech, by discrediting the opposition. ;)