There are two claims in the article. The first one, that Linux is not secure enough, is the one that I don't afraid at all. All of us knows that only troll will still think that they need a close source system in order to get security. All of us knows how open-source works to allow bugs, and in particular security holes, to be found and patched quickly.
But the second claim is somewhat more disturbing: that there is a trend that more people become trolls. If this is really such a trend, this has to be dealt with. Of course, there is every possibility that the article is once again funded by Microsoft to generate FUD.
But if not, what can be done? How new comers can be educated about security more readily than getting the FUD?
> If I were to write a piece of software that I'd > like reviewed by the open source community (and > I am), I will release it under a really free > license, then I can take any patches the > community submits and integrate them into my > "real" tree
Well... I'd really want such a world, but copyright law nearly prohibit this. People who write software does have a say about who is allowed to use that. Of course, unless the license of your own software prohibit modification unless it is contributed back to your tree.
I know only one license which goes that far (SCSL), and of course nobody really likes it. People does want the right to do modification and keep it private.
Getting what you want by the license helps little. But there are always motives that people want to contribute code back to your tree, even if the license does not mandate it. Right?
Hey... do you guys know whether this kind of things will be possible with Mozilla? I've heard that Mozilla uses Gtk+, and Gtk+ doesn't allow for resource files.
Why we want free software? If one read the Copying file of GPL, one would know the concern by Stallman. There are a lot of ways to use a piece of software, and most can be done by everybody in the world cheaply. When software are proprietary, all these uses becomes unrealistically expensive.
In an earlier article by Stallman (forgot which), he commented on the Open Hardware project. His vision is that Open Hardware is not as needed as free software, because modifying and making a new piece of hardware (i.e. chip) is expensive anyway.
Code Morphing is somewhere in between. You have to make a new hardware before you need actually rewrite code morphing substantially. In this way, most of the people who want access to source code of code morphing is probably hardware makers who want to produce a chip using the same technology, not the general public. There can be small changes to the code which is useful even without modifying the underlying hardware, but that is not going to be really necessary because on top of that the chip is completely programmable.
In this sense, I don't see there is a big need to free Crusoe, at least from a viewpoint I understand by reading Stallman's writing.
I'm actually wondering whether it could be a good thing (TM) for the US case.
The current status of the US case is basically this. The CSS key in DVD players are trade secrets protected by computer security software. It is a crime to unveil others' trade secrets obtained via unlawful channels. To get the trade secret, it is believed that the Xing Windows player is reverse engineered. Reverse engineering is unlawful in US when the software has a click license which prohibit this. Xing does have such click license in place. The reverse engineering is done in Norway, so US law may not apply. But there is no previous case in Norway, so nobody knows whether it is actually lawful there. Since the court cannot decide, it have to take the safe bet, temporarily forbidden sites to carry DeCSS.
As long as there is no case in Norway, the status won't change. MPAA can sue sites in basically every place in the world and stop DeCSS's distribution. Every place in the world, except in Norway, will be forbidden from the CSS keys, and thus the DeCSS code.
The whole argument collapse once there is a case in Norway saying that reverse engineering is allowed. Then the method used to obtain the trade secret, i.e. the CSS keys, is lawful. Then there is no more law to stop the "trade secret" from being unveiled. And MPAA has basically no way to ask for restriction of DeCSS.
I agree wholeheartly that the EFF guys have had a deadly wrong strategy on the case.
In fact, it actually get me puzzled to read the reports. Why the defendent argues by saying that "if we lose the case, we lose our right to talk about the insecurity of the DVD encryption scheme"? When posting the source, is it our intention "to help finding a better scheme for securing DVDs"?
What we actually want is that we will eventually be able to distribute binaries of DeCSS for playngi DVD in Linux. The above argument just cannot give us that!
What we actually want is the right for interoperability. What we want is that we can actually read every bit out of a DVD and know what it means. What we want is that we can legally write a software which reads a DVD. Not just to talk about the insecurity.
Imagine that MPAA tomorrow abolish the protection scheme of DVD as being "too weak to protect artists", and design a new scheme. Another hacker then spends a whole year of effort, decipher the whole thing so that we can read it with Linux, and put it onto the web. Should MPAA be able to stop us distributing the code?
However secure the DVD encoding is, I don't think we should be restricted in such way.
By arguing this way, the defendent shoot their own toes. On one hand, they say that the purpose of the code is to play DVD under Linux. On the other hand, they say the purpose of talking about it is to make DVD harder to be played. Just about anybody will see that they are simply contractory.
> emulating non-x86 architectures on Crusoe is > going to be possible, but noticeably harder and > slower than x86.
Did I read something that is really weird? Emulating x86 is the worst of the worst in terms of emulating a processor using another processor. It is simply too complicated.
> Power consumption of the chip is lower, but > power consumption of the chip is only 20-30% of > a notebook, limiting the value of this > "revolution."
The remaining goes to hard disks and display. For hard disks, we have solid state HD which might eventually get it down another 20-30%. Anybody know about what we can do about display efficiency in terms of power?
> In terms of integrating 3D, Intel has a huge > lead over Transmeta in terms of patent licensing > and technology development.
I'm an idiot here. What's wrong to just imitate the 3D instruction set of Intel? Would "fair use" to obtain "interoperability" guarantee that such approach won't be successfully sued?
> Did I mention the difficulties Transmeta would > have keeping up with Intel's clock rates and > performance?
I see the software approach for Crusoe a big win here. The complexity to increase clock speed is non-linearly proportional to the complexity of the hardware, not the software. Whether Intel will take Crusoe approach in its next chip (or buy out Transmeta) I can't be sure.
> How else do you expect development to get paid for?
This speaks in the point of view from the developer. When I ask why the "need", I'm asking from a point of view of the user. As a user, I see that Linux is there not asking you to pay to install it in my girlfriend's PC, I see that I can do the same for Windows except that the license didn't allow me to do so. So "developers need money" did not answer my question. I still cannot justify having to pay for something when it is available free--were Linux more "user-friendly". I still hold firmly that Linux should also be for the desktop.
While I did have a lot of religious believe and do think that everything, at least everything in generic use, should be free and preferably under GPL, I didn't actually mean that in my earlier posting.
> Should the price depend on how hard it was to do > the job? No, of course not. The price should be > based how useful the job is to you, ie: the > utility.
What an interesting idea. Mind you that everything else didn't work that way. It is rather easy to grow rice, so although rice is a vitally important to have, it is relatively cheap, for everyone else can produce rice and sell them that cheap, getting all the market from anyone who want to sell them more expensively. It is just the copyright law, which ensure a monopoly on software, cause the contrary to happen. I won't comment which is better, for I'm sure that it would be another round of flame war.
> end users will probably still end up paying > $60-$100 even if they were using Linux. The > difference is ,...
you can install it everywhere, you are not forced to pay for the "support" from the same place you get the software (which is what the $60-100 for). Distributors sell exactly for what they do: distributing software. Nothing more. People can use any other way to get a distribution if they don't want it from distributors. They get everything they would expect from a free market.
> It's so ironic that people point out Red Hat as > an "Open Source success story" when: 1. Red Hat > is losing money. (yes, I know their stock is > doing well, but so is Yahoo's) 2. Red Hat > doesn't develop the vast majority of the > software in their distribution.
It's not that accurate to say Red Hat is "losing money". I'd rather say that it is making substantial capital investment. It's revenue is much higher than any internet startup you can see. And Red Hat does write the package management system and sponsors many development efforts.
> They already make copies of Windows, despite > what the law says
You mean, you think it is reasonable to formulate laws so that people are forced to violate them? I must be from a different planet from yours.
> Why do people who only want to fart around on > the internet and read Email need Linux?
This is a wrong question to ask. And the answer to this wrongly asked question is very, very simple: because those applications needs a computer, which needs an operating system to run them. Linux is an operating system which fits the bill.
People routinely says they "don't need Linux". This shouldn't be read literally. What they mean is not that they don't need an open-source operating system like Linux to control their computers. What they mean is that Linux is still too troublesome, and there is no need for them to have that trouble. This is actually a complaint, not a statement of fact. That's why people starts to figure out what is needed: they need Linux, only that it is currently not up to par for them.
And the correct question to ask is, why people who only need to read E-mails and surf the web need to pay $100 every now and then for each of their computers just to run an operating system which cost nothing to make a copy for running on their computers?
> The MPL, however, contains no such restrictions, > but it does grant the licensee the ability to > create closed-source derived works, as long as > the original code and its mods are kept open. > Still not compatible with the GPL, due to the > GPL virus clause...
Did MPL contains a clause saying that any derived work must allow close-source derived work to be produced? If not, is it okay just to release the derived work in GPL?
> I'm just a rank beginner with linux, but have > been a WinNT programmer for some years now, and > have been long told that Microsoft's C compiler > has a way better optimizer than GCC does. Is > this true, and if so,
Probably not, if my memory work right. In fact, NT and Win98 programs are quite slower when compiled with Visual C, than when compiled with an independent commercial compiler, for numerical applications where compiler optimization can really make deep effects.
> how large an effect do you > think this will have on the performance of the > kernel and the modules tested (apache, samba, > etc)
Not much, I think. The problem is probably that the kernel does not allow that much parallelism in the network, that most of the time threads are waiting for the kernel rather than waiting for connections. For such non-CPU-bounded tasks, compiler optimization is nearly insignificant.
After reading all the postings here, I understand why some people are so angry about a late Debian. First off, staying in slink is difficult: there are hardware not supported, and those software which has only been Beta last year remains to be beta even if it is released 20 times during the year, and so on. Upgrading to Potato is sweet, but it is not an option for many system. First off it require large downloads if you already have a moderately large install base of slink. And there is nothing called security fixes in unstable: there is only a concept of "new", meaning that if you want a secure system you need to upgrade the whole system every day. Even worse, the package system does get broken every now and then (to perform package reorganization), making it impossible to upgrade a significant part of the system for quite a period of time (how long did you wait before upgrading all slang-using packages after slang-1.3 is released?).
But no, releasing Debian potato quick is not the solution. What's the biggest advantage of Debian? Stability and uniformity. Why people install Debian? Stability and uniformity. If one need to trade stablility and uniformity, say, with newer software, in order to compete with Redhat or SuSE, it will backfire and lose its loyal followers. Is there any way that release cycle is accelerated? Maybe. People are talking about it after releasing slink, after slink is freezed but not released for months. And the consensus is that potato still need to be slow to freeze.
There is one interesting thing to notice. Most people care only that they can run their system and their favorite software, not that the newest software ones are being installed. Even if Gnome 1.0.54 is now the current stable, people are reasonably happy with 1.0.5. But people are quite angry even with XFree 3.3.2, since quite some hardware supported by 3.3.5 are not there. They are not happy with libc6 delay, since then they cannot run their mozilla milestones (without compiling themselves). On the other hand, nobody is going to care that the Slink version of rosegarden crash much more frequently than that of Potato: they just compile their own and replace the binary. Also, for the worst lags, there are always unofficial debian packages installable on slink, just that the packages are always difficult to locate.
Why don't Debian people try to collect all links (or even archive) to these slink un-official packages? Only a few of them are needed to keep people happy using Debian. And since there are only few, it can even be placed into the bug tracking system.
Right. And they are already done. Did IE has XUL? What's their answer to MyNetscape?
But more seriously, what is need is much simpler: to ship soon. Mozilla is already a great browser. Everybody is waiting for Netscape 5 to erode market share back from IE.
> dselect is the most hated part of Debian. I much > much prefer the apt tools.
Dselect is really horrible if you just intend to install a single package. If you want to examine every package to see if you want it, it is quite acceptable. On an unstable system where you usually want to upgrade all the package except all X-related ones (that would lock me out!), dselect is just wonderful. But when unsatisfiable dependencies of old packages starts looping the whole process of dselect, you will wonder why there cannot be something better.
As the major tool to update Debian, dselect is not quite up-to-standard. On the other, as a handy tool, it is quite useful.
> In what way will Netscape 5 be a quantum leap > over Netscape 4? > More stable? Faster? Less bloaty?
Hmmm... yes, these won't make it a "quantum leap".
But I don't think Netscape 5, and in general Mozilla, is all about having a more efficient and less buggy browser. It's about having a browser which people can really "work with", as oppose to just "use".
How about standard compliance? Mozilla is completely standard compliant, easing web developers a real lot on developing applications which works on all browsers.
How about XUL? Now you can have a say about the "look and feel" of your browser, finally. No more talk about "they place a useless My Netscape button there that I never use!".
How about being built as a library as well as a program? Now your desktop application that want to emit a help message doesn't need to create a full browser to do that. You can really start to write programs that contain a browser-like widget.
How about XML support? Now you don't have to wait for minutes downloading graphics just to download the stupid equations: MathML do all that just using text. And all the XML applications.
How about a more open architecture? Now you can easily plug in whatever component to the browser so that it support strong cryptography, which cannot be supported due to the stupid US export regulation.
How about a more open development model? Now if you find a bug, or a feature of IE that is not supported by Mozilla, you can put in a bug report and see how it get resolved. You can even grasp the source and do it yourselves.
Do you really mean all these are just "bug fixes"? I'd say, it's quite a quantum leap, indeed.
I've been using Dvorak for quite some time now (around 12 months). I feel discomfort using it only for the first month. After that, everything goes as good as, if not better than, my qwerty days.
First, I'd make it clear how I count "ease of typing" for a particular key or sequence. I don't exactly like typing on the bottom row: it cause my fingers to curl more than I'd really like. I don't like keys to be too far from the home keys either, and like index finger and middle finger typing more than ring finger and little finger typing. So the qwerty locations for f is better than s, than r, than t, than 3, than 5, and then than = and finally than backspace. I don't like typing two different letter consecutively using the same finger: it is surely slow to type, and rather tiring.
Now, for the symbols you've mentioned ({};&>.[]+=-*%!), four of them didn't change location (&*%!), four gets more convenient (+=->), and five gets less convenient ({}[];). I didn't mind too much for the braces and brackets anyway, since I always type them at the same time (whenever I type { I also want }, so it didn't matter all so much, and would configure my editor to automatically add the other for me). All in all it is about balanced out, and any discomfort should be due to initial learning process.
For the Unix commands you've mentioned, some really gets rather difficult to type (in particular, ls). Some in fact get easier (in particular, ftp). Again, it should balance out: after all, they are simply random selection of letters to represent the full name of the command.
My comment about Dvorak coding is simple: I don't sense anything bad about it, and there is something good: it promote the use of more sensible identifier (since Dvorak are optimized for words, not for acronyms).
And I don't particularly like voice recognition. I type much better than I speak, in fact.
Re:Pedantic and preachy, but agreeable
on
Is X The Future?
·
· Score: 1
> I'd really hate to try running Quake2, even > through GLX, on a remote display. The latency > would be absolutely *horrible*...
Yes, you may find it too slow. Someone will, someone won't. But if the program code complain and exit immediately on servers without share memory, the user has no choice. He won't even be able to see whether it is "too slow" for him.
> (since there's absolutely no way to do that > server-side without relying on GLX, which, if it > doesn't exist on the server, needs to be done in > software on the client leading to - guess what - > bandwidth! AND horrific CPU/memory usage!).
Then why don't implement a GLX module on every X implementation instead of building a new thing? And of course, if the lack of GLX lead to large bandwidth requirement, that "large bandwidth requirement" is the "minimum requirement" for that system, and nobody is going to charge you wasting bandwidth.
> any extensions... lead to the exact same > situation, namely a shitload of X servers which > won't be able to run these programs.
The difference being that at least I can continue to run my old applications, and I can hope to be able to run the new program together with the old ones. If I want some new extension, I just need to write that, instead of a whole new windowing environment.
> you can't talk about its total acceptance and > suggest making new protocol extensions either
You can. Not every people need the same set of extension. I, for one, never need any input extension, and never load the PEX module into my server. That doesn't mean either is not being accepted. I'll find it when the need arises. Being extendable is a beauty of X, not a baggage.
There is a single difference that makes me worry: it is completely controlled by human beings.
Just like I'm not comfortable with Microsoft controlling the whole computing community, just like I'm not comfortable with US (or any other nation) controlling all the world. I'm not comfortable with human beings controlling the whole process of reproduction.
In evolution, each species struggle to maximize the chance that the species surrive. Therefore, natural cloning is always small-scale, and do not affect the chance that human surrive in face of environmental changes.
Human decisions are, on the other hand, not always trying to optimize the chance of surrival. Our other desires, like economical and emotional, are good reasons for us to worry.
While I worry, but not reject. I think this technology can be made into good use if people use it wisely (enough).
Don't forget to check Zmailer then. The following is its description in the Linux Debian package:
zmailer - Mailer for Extreme Performance Demands
This is a package that implements an internet message transfer agent called ZMailer. It is intended for gateways or mail servers or other large site environments that have extreme demands on the abilities of the mailer. It was motivated by the problems of the Sendmail design in such situations. Zmailer is one of the mailers able to deal with huge quantities of mail and is more efficient any other mailer, qmail included.
> By running the apps locally I am not constrained > by network going down or bandwidth problem.
Perfectly right observation. If you do not want to bother about network downtime, don't rely on file server to host your software. Don't rely on network login system to host your login information. That way you're sure to be locked out when network fails.
But then for Linux, it is your choice. You can use NFS and NIS on a network which is usually up. You can make it standalone and manage all the binaries yourselves. You can use rdist to distribute software to your machine from the server automatically every night, avoid the need to track with security patches and new versions, while not lagging behind for too long. You find the BEST solution for your situation.
Not so for NT. You will have to take the trouble managing registry, and most likely this HAVE to be done by individually installing the software on each machine.
> At the rate IT is shoving stuff down our throat, > I will put the corporate computer aside and > bring my own one to do my job as best as I can > do and not according to some IT guy who thinks > he knows all about my application and loads the > vanilla flavour of it.
Good luck, then. You should understand that by doing this, you are taking up another job of system administration. Many people enjoy this, and I do like managing my own Linux cluster. But I can only enjoy this when updating the system can be done automatically (I'm using Debian). I remember that I hate the need to update my system every now and then on my Slackware system: I have to look at individual package, check whether it is old, read README file, and install it. Unless you only have a couple of applications to keep updated, you'll definitely get tired of it.
Most Linux applications ARE user configurable through environment variables. After doing your own customizations, you can start relying on your system admins to upgrade the software. No more constant peeping at web site.
It seems to me that it is library organization problem rather than a linker problem. After all, the linker do just the simplest thing: get in object, find all unresolved symbols, jam in all objects that provides any of the unresolved symbols and repeat. It seems to me that the library contains too much inter-dependencies, which cause most of the library object files to be included into the final binary. Can anybody confirm or disprove this?
By the way, I cannot reproduce the results shown in other posts. My hello world compilation gives 89k stripped static binary and 3k stripped shared binary. Here's what I used:
If you can see through the reason why Microsoft sponsors and eventually published the Mindcraft report, you know exactly why the Linux community need to say "NO".
Suppose that your manager receive a phone call from a Microsoft salesman and want to switch their Linux server to NT (for whatever non-technical reason). Without other rationale, you, as a technical support, will nearly definitely says it will be difficult to manage, cause performance loss, requires more money, etc., and finally ask the manager to reconsider and abandon the decision.
But if the managers hold a copy of Mindcraft report and says that he need more performance and it cannot be accompolished with Linux, you won't have much to say.
Except that you also hold a copy of rebuttal telling exactly where the Mindcraft report went wrong. That is, it is not that Linux cannot be configured to beat a well-tuned NT. It can, and it can do it easily. Just that it requires some expertise which Mindcraft didn't have, and that such expertise will be easier to be obtained after the Mindcraft report.
This is exactly what the LinuxWorld article of Jeremy Allison is for. Essentially, it says "its not difficult to configure Samba much better and outperform a well tuned NT, here are the details. And we will find ways to teach system adminstrators about what's needed in the next release."
Quite a number of people here suggested that copyrights are good because it is the base of "GPL" or "Open Source". I don't think that is a correct reasoning. If there were not "copyright", we do not need "GPL".
Just imagine what is the obligation and power of both the producer and consumer of software. With GPL, both have no obligation. If somebody asked you for a copy, you can refuse: for whatever reason. Both have most of the power, because both can, if they want, copy, distribute and modify the software. The only thing that can't be done is to give a copy to others BUT says "you cannot copy, distribute or modify" the software. There is one exception: the producer can produce a modified version and change the license term. If you think GPL is good, you won't like this. But it is the fact.
What if there's no copyright law? If that were the case, the legal system do not regard software as something which can be "owned" or "controlled" by individual. Only "physical" representation of the software (like disk, CD, tape, etc) can. Again, both the producer and the consumer have no obligation. And the consumer, not abided by any sort of enforcable law, can also make copy, distribute, and modify the software. The only difference is that the producer can no longer change the license: it is always something like GPL.
In my opinion, GPL is something which use the copyright system to negate the power of copyright system. There is not much point to say "GPL is good, so copyright is good". If you think everything should be GPL, there shouldn't be copyright law in the first place.
More thinking about the articles and about Dvorak
on
The Myth of QWERTY
·
· Score: 1
First of all, my alignment. I've been typing QWERTY for 11 years beginning when I'm just a F.2 (in US standards, Grade 8) student. I didn't really choose QWERTY: there's no choice. I learnt it because I think it is useful. And I learnt about Dvorak a year ago and really tried that and converted myself to be a Dvorak typist 3 months ago.
Back to the article now. Frankly speaking, I do not see what's the objective of the article, which is my first question. It seems to me that it tries to convince people that the Dvorak failure is not due to market failure. But that is the subject of the cited work "The Fable of the Keys", and this article seems to add no more argument nor additional evidence. It is just a restatement or reference to such work.
I've tried to read earlier posts here. I found reference to an article "Should technology choice be a concern of antitrust policy?", which use the cited work as a basis for the assertion that market failure did not apply to QWERTY. But then, after reading a little bit further, I found that "The Fable of Keys" asserted that "The benefit of Dvorak does not justify retraining of staffs", which is exactly a standard lock-in. I started to wonder how people actually think.
In fact, I believe the methodology of this work does not make much sense when the question is about "Is Dvorak better than QWERTY". It compares the rate of improvement between new Dvorak typists and old QWERTY typists. The Dvorak group does not enjoy the years of experience of typing enjoyed by QWERTY typists, and have never even attempted to type faster than they currently did. They doesn't even have a good motivation to try type faster, where QWERTY typists have abundent of reasons to try typing faster. Nor did the study addresses issues other than typing speed. If what you study is "which keymap is better", you got to use another experient, which employ individuals who never learnt how to type and never told about any story about which keymap is better. Without that sample, we have to rely on our own experience to "guess" which is better.
There is one point that is sure: were we to run such an experiment, a Dvorak group will learn much faster. That is because that they do not waste time familiarize themselves on meaningless "words" like "asdf" and "jkl;". As they get familiar with the home row, they get familiar with the words that they use most frequently in the future. I think anybody familiar with education know how important this is.
I also read posts that explaint how they abandon Dvorak when they started the vi editor. I usually use Emacs, and since Emacs keymaps are generally keyboard-neutral I've no such problem. When I did use vi I did comes up with the problems suggested by that post. But after a while, I found that it is not that uncomfortable using vi with Dvorak. Yes, there's no hjkl convenience. But are j and k really that far away? Not quite. How about h and l? Yes, they are really horrible. But there is something to balance that out: w and b are quite near and reachable in Dvorak. Back on QWERTY, it is horrible to repeatedly type w and b. Don't forget that word movements are much more efficient way to navigate your text.
Then I try to find things that I can do and cannot do after switching to Dvorak, and try to find the missing links that prevent wide adoption. The only reason is: a huge switching cost. You have to renew every keyboard. And if you cannot make it happen overnight, we split ourselves into two parties typing different keyboards and cannot work on same machines. Modern operating systems does provide better "upgrade path", since you can install both keyboard mapping to a Win95 or Linux machine. But whenever you work at a new site, you end up doing the same exercise again. And nobody yet find THE way to switch between keymaps. Adding to the already long story, you have to relearn every application keymap. I've said that Emacs is keyboard neutral, but that does not mean your brain use the keyboard neutral bindings. Any Dvorak learner will learn his lesson that your brain directly map the functionality like "next line" to positions on the keyboard like "left little finger left and down followed by striking the key left-low" (control-n). It needs quite some time to retrain your brain to use the keyboard neutral mapping, but soon it turns back to a (new) keyboard sensitive binding.
But that's not about which is better. That's about which is being used. What's being used is not necessarily what's better.
Slashdot Mirror
There are two claims in the article. The first one, that Linux is not secure enough, is the one that I don't afraid at all. All of us knows that only troll will still think that they need a close source system in order to get security. All of us knows how open-source works to allow bugs, and in particular security holes, to be found and patched quickly.
But the second claim is somewhat more disturbing: that there is a trend that more people become trolls. If this is really such a trend, this has to be dealt with. Of course, there is every possibility that the article is once again funded by Microsoft to generate FUD.
But if not, what can be done? How new comers can be educated about security more readily than getting the FUD?
> If I were to write a piece of software that I'd
> like reviewed by the open source community (and
> I am), I will release it under a really free
> license, then I can take any patches the
> community submits and integrate them into my
> "real" tree
Well... I'd really want such a world, but copyright law nearly prohibit this. People who write software does have a say about who is allowed to use that. Of course, unless the license of your own software prohibit modification unless it is contributed back to your tree.
I know only one license which goes that far (SCSL), and of course nobody really likes it. People does want the right to do modification and keep it private.
Getting what you want by the license helps little. But there are always motives that people want to contribute code back to your tree, even if the license does not mandate it. Right?
Hey... do you guys know whether this kind of things will be possible with Mozilla? I've heard that Mozilla uses Gtk+, and Gtk+ doesn't allow for resource files.
But of course, maybe themes and XUL are better.
Why we want free software? If one read the Copying file of GPL, one would know the concern by Stallman. There are a lot of ways to use a piece of software, and most can be done by everybody in the world cheaply. When software are proprietary, all these uses becomes unrealistically expensive.
In an earlier article by Stallman (forgot which), he commented on the Open Hardware project. His vision is that Open Hardware is not as needed as free software, because modifying and making a new piece of hardware (i.e. chip) is expensive anyway.
Code Morphing is somewhere in between. You have to make a new hardware before you need actually rewrite code morphing substantially. In this way, most of the people who want access to source code of code morphing is probably hardware makers who want to produce a chip using the same technology, not the general public. There can be small changes to the code which is useful even without modifying the underlying hardware, but that is not going to be really necessary because on top of that the chip is completely programmable.
In this sense, I don't see there is a big need to free Crusoe, at least from a viewpoint I understand by reading Stallman's writing.
I'm actually wondering whether it could be a good thing (TM) for the US case.
The current status of the US case is basically this. The CSS key in DVD players are trade secrets protected by computer security software. It is a crime to unveil others' trade secrets obtained via unlawful channels. To get the trade secret, it is believed that the Xing Windows player is reverse engineered. Reverse engineering is unlawful in US when the software has a click license which prohibit this. Xing does have such click license in place. The reverse engineering is done in Norway, so US law may not apply. But there is no previous case in Norway, so nobody knows whether it is actually lawful there. Since the court cannot decide, it have to take the safe bet, temporarily forbidden sites to carry DeCSS.
As long as there is no case in Norway, the status won't change. MPAA can sue sites in basically every place in the world and stop DeCSS's distribution. Every place in the world, except in Norway, will be forbidden from the CSS keys, and thus the DeCSS code.
The whole argument collapse once there is a case in Norway saying that reverse engineering is allowed. Then the method used to obtain the trade secret, i.e. the CSS keys, is lawful. Then there is no more law to stop the "trade secret" from being unveiled. And MPAA has basically no way to ask for restriction of DeCSS.
Anything wrong?
I agree wholeheartly that the EFF guys have had a deadly wrong strategy on the case.
In fact, it actually get me puzzled to read the reports. Why the defendent argues by saying that "if we lose the case, we lose our right to talk about the insecurity of the DVD encryption scheme"? When posting the source, is it our intention "to help finding a better scheme for securing DVDs"?
What we actually want is that we will eventually be able to distribute binaries of DeCSS for playngi DVD in Linux. The above argument just cannot give us that!
What we actually want is the right for interoperability. What we want is that we can actually read every bit out of a DVD and know what it means. What we want is that we can legally write a software which reads a DVD. Not just to talk about the insecurity.
Imagine that MPAA tomorrow abolish the protection scheme of DVD as being "too weak to protect artists", and design a new scheme. Another hacker then spends a whole year of effort, decipher the whole thing so that we can read it with Linux, and put it onto the web. Should MPAA be able to stop us distributing the code?
However secure the DVD encoding is, I don't think we should be restricted in such way.
By arguing this way, the defendent shoot their own toes. On one hand, they say that the purpose of the code is to play DVD under Linux. On the other hand, they say the purpose of talking about it is to make DVD harder to be played. Just about anybody will see that they are simply contractory.
> emulating non-x86 architectures on Crusoe is
> going to be possible, but noticeably harder and
> slower than x86.
Did I read something that is really weird? Emulating x86 is the worst of the worst in terms of emulating a processor using another processor. It is simply too complicated.
> Power consumption of the chip is lower, but
> power consumption of the chip is only 20-30% of
> a notebook, limiting the value of this
> "revolution."
The remaining goes to hard disks and display. For hard disks, we have solid state HD which might eventually get it down another 20-30%. Anybody know about what we can do about display efficiency in terms of power?
> In terms of integrating 3D, Intel has a huge
> lead over Transmeta in terms of patent licensing
> and technology development.
I'm an idiot here. What's wrong to just imitate the 3D instruction set of Intel? Would "fair use" to obtain "interoperability" guarantee that such approach won't be successfully sued?
> Did I mention the difficulties Transmeta would
> have keeping up with Intel's clock rates and
> performance?
I see the software approach for Crusoe a big win here. The complexity to increase clock speed is non-linearly proportional to the complexity of the hardware, not the software. Whether Intel will take Crusoe approach in its next chip (or buy out Transmeta) I can't be sure.
> How else do you expect development to get paid for?
...
This speaks in the point of view from the developer. When I ask why the "need", I'm asking from a point of view of the user. As a user, I see that Linux is there not asking you to pay to install it in my girlfriend's PC, I see that I can do the same for Windows except that the license didn't allow me to do so. So "developers need money" did not answer my question. I still cannot justify having to pay for something when it is available free--were Linux more "user-friendly". I still hold firmly that Linux should also be for the desktop.
While I did have a lot of religious believe and do think that everything, at least everything in generic use, should be free and preferably under GPL, I didn't actually mean that in my earlier posting.
> Should the price depend on how hard it was to do
> the job? No, of course not. The price should be
> based how useful the job is to you, ie: the
> utility.
What an interesting idea. Mind you that everything else didn't work that way. It is rather easy to grow rice, so although rice is a vitally important to have, it is relatively cheap, for everyone else can produce rice and sell them that cheap, getting all the market from anyone who want to sell them more expensively. It is just the copyright law, which ensure a monopoly on software, cause the contrary to happen. I won't comment which is better, for I'm sure that it would be another round of flame war.
> end users will probably still end up paying
> $60-$100 even if they were using Linux. The
> difference is ,
you can install it everywhere, you are not forced to pay for the "support" from the same place you get the software (which is what the $60-100 for). Distributors sell exactly for what they do: distributing software. Nothing more. People can use any other way to get a distribution if they don't want it from distributors. They get everything they would expect from a free market.
> It's so ironic that people point out Red Hat as
> an "Open Source success story" when: 1. Red Hat
> is losing money. (yes, I know their stock is
> doing well, but so is Yahoo's) 2. Red Hat
> doesn't develop the vast majority of the
> software in their distribution.
It's not that accurate to say Red Hat is "losing money". I'd rather say that it is making substantial capital investment. It's revenue is much higher than any internet startup you can see. And Red Hat does write the package management system and sponsors many development efforts.
> They already make copies of Windows, despite
> what the law says
You mean, you think it is reasonable to formulate laws so that people are forced to violate them? I must be from a different planet from yours.
> Why do people who only want to fart around on
> the internet and read Email need Linux?
This is a wrong question to ask. And the answer to this wrongly asked question is very, very simple: because those applications needs a computer, which needs an operating system to run them. Linux is an operating system which fits the bill.
People routinely says they "don't need Linux". This shouldn't be read literally. What they mean is not that they don't need an open-source operating system like Linux to control their computers. What they mean is that Linux is still too troublesome, and there is no need for them to have that trouble. This is actually a complaint, not a statement of fact. That's why people starts to figure out what is needed: they need Linux, only that it is currently not up to par for them.
And the correct question to ask is, why people who only need to read E-mails and surf the web need to pay $100 every now and then for each of their computers just to run an operating system which cost nothing to make a copy for running on their computers?
> The MPL, however, contains no such restrictions,
> but it does grant the licensee the ability to
> create closed-source derived works, as long as
> the original code and its mods are kept open.
> Still not compatible with the GPL, due to the
> GPL virus clause...
Did MPL contains a clause saying that any derived work must allow close-source derived work to be produced? If not, is it okay just to release the derived work in GPL?
> I'm just a rank beginner with linux, but have
> been a WinNT programmer for some years now, and
> have been long told that Microsoft's C compiler
> has a way better optimizer than GCC does. Is
> this true, and if so,
Probably not, if my memory work right. In fact, NT and Win98 programs are quite slower when compiled with Visual C, than when compiled with an independent commercial compiler, for numerical applications where compiler optimization can really make deep effects.
> how large an effect do you
> think this will have on the performance of the
> kernel and the modules tested (apache, samba,
> etc)
Not much, I think. The problem is probably that the kernel does not allow that much parallelism in the network, that most of the time threads are waiting for the kernel rather than waiting for connections. For such non-CPU-bounded tasks, compiler optimization is nearly insignificant.
After reading all the postings here, I understand why some people are so angry about a late Debian. First off, staying in slink is difficult: there are hardware not supported, and those software which has only been Beta last year remains to be beta even if it is released 20 times during the year, and so on. Upgrading to Potato is sweet, but it is not an option for many system. First off it require large downloads if you already have a moderately large install base of slink. And there is nothing called security fixes in unstable: there is only a concept of "new", meaning that if you want a secure system you need to upgrade the whole system every day. Even worse, the package system does get broken every now and then (to perform package reorganization), making it impossible to upgrade a significant part of the system for quite a period of time (how long did you wait before upgrading all slang-using packages after slang-1.3 is released?).
But no, releasing Debian potato quick is not the solution. What's the biggest advantage of Debian? Stability and uniformity. Why people install Debian? Stability and uniformity. If one need to trade stablility and uniformity, say, with newer software, in order to compete with Redhat or SuSE, it will backfire and lose its loyal followers. Is there any way that release cycle is accelerated? Maybe. People are talking about it after releasing slink, after slink is freezed but not released for months. And the consensus is that potato still need to be slow to freeze.
There is one interesting thing to notice. Most people care only that they can run their system and their favorite software, not that the newest software ones are being installed. Even if Gnome 1.0.54 is now the current stable, people are reasonably happy with 1.0.5. But people are quite angry even with XFree 3.3.2, since quite some hardware supported by 3.3.5 are not there. They are not happy with libc6 delay, since then they cannot run their mozilla milestones (without compiling themselves). On the other hand, nobody is going to care that the Slink version of rosegarden crash much more frequently than that of Potato: they just compile their own and replace the binary. Also, for the worst lags, there are always unofficial debian packages installable on slink, just that the packages are always difficult to locate.
Why don't Debian people try to collect all links (or even archive) to these slink un-official packages? Only a few of them are needed to keep people happy using Debian. And since there are only few, it can even be placed into the bug tracking system.
Right. And they are already done. Did IE has XUL? What's their answer to MyNetscape?
But more seriously, what is need is much simpler: to ship soon. Mozilla is already a great browser. Everybody is waiting for Netscape 5 to erode market share back from IE.
> dselect is the most hated part of Debian. I much
> much prefer the apt tools.
Dselect is really horrible if you just intend to install a single package. If you want to examine every package to see if you want it, it is quite acceptable. On an unstable system where you usually want to upgrade all the package except all X-related ones (that would lock me out!), dselect is just wonderful. But when unsatisfiable dependencies of old packages starts looping the whole process of dselect, you will wonder why there cannot be something better.
As the major tool to update Debian, dselect is not quite up-to-standard. On the other, as a handy tool, it is quite useful.
> In what way will Netscape 5 be a quantum leap
> over Netscape 4?
> More stable? Faster? Less bloaty?
Hmmm... yes, these won't make it a "quantum leap".
But I don't think Netscape 5, and in general Mozilla, is all about having a more efficient and less buggy browser. It's about having a browser which people can really "work with", as oppose to just "use".
How about standard compliance? Mozilla is completely standard compliant, easing web developers a real lot on developing applications which works on all browsers.
How about XUL? Now you can have a say about the "look and feel" of your browser, finally. No more talk about "they place a useless My Netscape button there that I never use!".
How about being built as a library as well as a program? Now your desktop application that want to emit a help message doesn't need to create a full browser to do that. You can really start to write programs that contain a browser-like widget.
How about XML support? Now you don't have to wait for minutes downloading graphics just to download the stupid equations: MathML do all that just using text. And all the XML applications.
How about a more open architecture? Now you can easily plug in whatever component to the browser so that it support strong cryptography, which cannot be supported due to the stupid US export regulation.
How about a more open development model? Now if you find a bug, or a feature of IE that is not supported by Mozilla, you can put in a bug report and see how it get resolved. You can even grasp the source and do it yourselves.
Do you really mean all these are just "bug fixes"? I'd say, it's quite a quantum leap, indeed.
I've been using Dvorak for quite some time now (around 12 months). I feel discomfort using it only for the first month. After that, everything goes as good as, if not better than, my qwerty days.
First, I'd make it clear how I count "ease of typing" for a particular key or sequence. I don't exactly like typing on the bottom row: it cause my fingers to curl more than I'd really like. I don't like keys to be too far from the home keys either, and like index finger and middle finger typing more than ring finger and little finger typing. So the qwerty locations for f is better than s, than r, than t, than 3, than 5, and then than = and finally than backspace. I don't like typing two different letter consecutively using the same finger: it is surely slow to type, and rather tiring.
Now, for the symbols you've mentioned ({};&>.[]+=-*%!), four of them didn't change location (&*%!), four gets more convenient (+=->), and five gets less convenient ({}[];). I didn't mind too much for the braces and brackets anyway, since I always type them at the same time (whenever I type { I also want }, so it didn't matter all so much, and would configure my editor to automatically add the other for me). All in all it is about balanced out, and any discomfort should be due to initial learning process.
For the Unix commands you've mentioned, some really gets rather difficult to type (in particular, ls). Some in fact get easier (in particular, ftp). Again, it should balance out: after all, they are simply random selection of letters to represent the full name of the command.
My comment about Dvorak coding is simple: I don't sense anything bad about it, and there is something good: it promote the use of more sensible identifier (since Dvorak are optimized for words, not for acronyms).
And I don't particularly like voice recognition. I type much better than I speak, in fact.
> I'd really hate to try running Quake2, even
... lead to the exact same
> through GLX, on a remote display. The latency
> would be absolutely *horrible*...
Yes, you may find it too slow. Someone will, someone won't. But if the program code complain and exit immediately on servers without share memory, the user has no choice. He won't even be able to see whether it is "too slow" for him.
> (since there's absolutely no way to do that
> server-side without relying on GLX, which, if it
> doesn't exist on the server, needs to be done in
> software on the client leading to - guess what -
> bandwidth! AND horrific CPU/memory usage!).
Then why don't implement a GLX module on every X implementation instead of building a new thing? And of course, if the lack of GLX lead to large bandwidth requirement, that "large bandwidth requirement" is the "minimum requirement" for that system, and nobody is going to charge you wasting bandwidth.
> any extensions
> situation, namely a shitload of X servers which
> won't be able to run these programs.
The difference being that at least I can continue to run my old applications, and I can hope to be able to run the new program together with the old ones. If I want some new extension, I just need to write that, instead of a whole new windowing environment.
> you can't talk about its total acceptance and
> suggest making new protocol extensions either
You can. Not every people need the same set of extension. I, for one, never need any input extension, and never load the PEX module into my server. That doesn't mean either is not being accepted. I'll find it when the need arises. Being extendable is a beauty of X, not a baggage.
There is a single difference that makes me worry: it is completely controlled by human beings.
Just like I'm not comfortable with Microsoft controlling the whole computing community, just like I'm not comfortable with US (or any other nation) controlling all the world. I'm not comfortable with human beings controlling the whole process of reproduction.
In evolution, each species struggle to maximize the chance that the species surrive. Therefore, natural cloning is always small-scale, and do not affect the chance that human surrive in face of environmental changes.
Human decisions are, on the other hand, not always trying to optimize the chance of surrival. Our other desires, like economical and emotional, are good reasons for us to worry.
While I worry, but not reject. I think this technology can be made into good use if people use it wisely (enough).
Don't forget to check Zmailer then. The following is its description in the Linux Debian package:
> By running the apps locally I am not constrained
> by network going down or bandwidth problem.
Perfectly right observation. If you do not want to bother about network downtime, don't rely on file server to host your software. Don't rely on network login system to host your login information. That way you're sure to be locked out when network fails.
But then for Linux, it is your choice. You can use NFS and NIS on a network which is usually up. You can make it standalone and manage all the binaries yourselves. You can use rdist to distribute software to your machine from the server automatically every night, avoid the need to track with security patches and new versions, while not lagging behind for too long. You find the BEST solution for your situation.
Not so for NT. You will have to take the trouble managing registry, and most likely this HAVE to be done by individually installing the software on each machine.
> At the rate IT is shoving stuff down our throat,
> I will put the corporate computer aside and
> bring my own one to do my job as best as I can
> do and not according to some IT guy who thinks
> he knows all about my application and loads the
> vanilla flavour of it.
Good luck, then. You should understand that by doing this, you are taking up another job of system administration. Many people enjoy this, and I do like managing my own Linux cluster. But I can only enjoy this when updating the system can be done automatically (I'm using Debian). I remember that I hate the need to update my system every now and then on my Slackware system: I have to look at individual package, check whether it is old, read README file, and install it. Unless you only have a couple of applications to keep updated, you'll definitely get tired of it.
Most Linux applications ARE user configurable through environment variables. After doing your own customizations, you can start relying on your system admins to upgrade the software. No more constant peeping at web site.
It seems to me that it is library organization problem rather than a linker problem. After all, the linker do just the simplest thing: get in object, find all unresolved symbols, jam in all objects that provides any of the unresolved symbols and repeat. It seems to me that the library contains too much inter-dependencies, which cause most of the library object files to be included into the final binary. Can anybody confirm or disprove this?
/lib/libc-*
By the way, I cannot reproduce the results shown in other posts. My hello world compilation gives 89k stripped static binary and 3k stripped shared binary. Here's what I used:
> g++ --version
egcs-2.91.60
> ls
/lib/libc-2.0.7.so
The system is a Debian slink system, by the way.
If you can see through the reason why Microsoft sponsors and eventually published the Mindcraft report, you know exactly why the Linux community need to say "NO".
Suppose that your manager receive a phone call from a Microsoft salesman and want to switch their Linux server to NT (for whatever non-technical reason). Without other rationale, you, as a technical support, will nearly definitely says it will be difficult to manage, cause performance loss, requires more money, etc., and finally ask the manager to reconsider and abandon the decision.
But if the managers hold a copy of Mindcraft report and says that he need more performance and it cannot be accompolished with Linux, you won't have much to say.
Except that you also hold a copy of rebuttal telling exactly where the Mindcraft report went wrong. That is, it is not that Linux cannot be configured to beat a well-tuned NT. It can, and it can do it easily. Just that it requires some expertise which Mindcraft didn't have, and that such expertise will be easier to be obtained after the Mindcraft report.
This is exactly what the LinuxWorld article of Jeremy Allison is for. Essentially, it says "its not difficult to configure Samba much better and outperform a well tuned NT, here are the details. And we will find ways to teach system adminstrators about what's needed in the next release."
Quite a number of people here suggested that copyrights are good because it is the base of "GPL" or "Open Source". I don't think that is a correct reasoning. If there were not "copyright", we do not need "GPL".
Just imagine what is the obligation and power of both the producer and consumer of software. With GPL, both have no obligation. If somebody asked you for a copy, you can refuse: for whatever reason. Both have most of the power, because both can, if they want, copy, distribute and modify the software. The only thing that can't be done is to give a copy to others BUT says "you cannot copy, distribute or modify" the software. There is one exception: the producer can produce a modified version and change the license term. If you think GPL is good, you won't like this. But it is the fact.
What if there's no copyright law? If that were the case, the legal system do not regard software as something which can be "owned" or "controlled" by individual. Only "physical" representation of the software (like disk, CD, tape, etc) can. Again, both the producer and the consumer have no obligation. And the consumer, not abided by any sort of enforcable law, can also make copy, distribute, and modify the software. The only difference is that the producer can no longer change the license: it is always something like GPL.
In my opinion, GPL is something which use the copyright system to negate the power of copyright system. There is not much point to say "GPL is good, so copyright is good". If you think everything should be GPL, there shouldn't be copyright law in the first place.
First of all, my alignment. I've been typing QWERTY for 11 years beginning when I'm just a F.2 (in US standards, Grade 8) student. I didn't really choose QWERTY: there's no choice. I learnt it because I think it is useful. And I learnt about Dvorak a year ago and really tried that and converted myself to be a Dvorak typist 3 months ago.
Back to the article now. Frankly speaking, I do not see what's the objective of the article, which is my first question. It seems to me that it tries to convince people that the Dvorak failure is not due to market failure. But that is the subject of the cited work "The Fable of the Keys", and this article seems to add no more argument nor additional evidence. It is just a restatement or reference to such work.
I've tried to read earlier posts here. I found reference to an article "Should technology choice be a concern of antitrust policy?", which use the cited work as a basis for the assertion that market failure did not apply to QWERTY. But then, after reading a little bit further, I found that "The Fable of Keys" asserted that "The benefit of Dvorak does not justify retraining of staffs", which is exactly a standard lock-in. I started to wonder how people actually think.
In fact, I believe the methodology of this work does not make much sense when the question is about "Is Dvorak better than QWERTY". It compares the rate of improvement between new Dvorak typists and old QWERTY typists. The Dvorak group does not enjoy the years of experience of typing enjoyed by QWERTY typists, and have never even attempted to type faster than they currently did. They doesn't even have a good motivation to try type faster, where QWERTY typists have abundent of reasons to try typing faster. Nor did the study addresses issues other than typing speed. If what you study is "which keymap is better", you got to use another experient, which employ individuals who never learnt how to type and never told about any story about which keymap is better. Without that sample, we have to rely on our own experience to "guess" which is better.
There is one point that is sure: were we to run such an experiment, a Dvorak group will learn much faster. That is because that they do not waste time familiarize themselves on meaningless "words" like "asdf" and "jkl;". As they get familiar with the home row, they get familiar with the words that they use most frequently in the future. I think anybody familiar with education know how important this is.
I also read posts that explaint how they abandon Dvorak when they started the vi editor. I usually use Emacs, and since Emacs keymaps are generally keyboard-neutral I've no such problem. When I did use vi I did comes up with the problems suggested by that post. But after a while, I found that it is not that uncomfortable using vi with Dvorak. Yes, there's no hjkl convenience. But are j and k really that far away? Not quite. How about h and l? Yes, they are really horrible. But there is something to balance that out: w and b are quite near and reachable in Dvorak. Back on QWERTY, it is horrible to repeatedly type w and b. Don't forget that word movements are much more efficient way to navigate your text.
Then I try to find things that I can do and cannot do after switching to Dvorak, and try to find the missing links that prevent wide adoption. The only reason is: a huge switching cost. You have to renew every keyboard. And if you cannot make it happen overnight, we split ourselves into two parties typing different keyboards and cannot work on same machines. Modern operating systems does provide better "upgrade path", since you can install both keyboard mapping to a Win95 or Linux machine. But whenever you work at a new site, you end up doing the same exercise again. And nobody yet find THE way to switch between keymaps. Adding to the already long story, you have to relearn every application keymap. I've said that Emacs is keyboard neutral, but that does not mean your brain use the keyboard neutral bindings. Any Dvorak learner will learn his lesson that your brain directly map the functionality like "next line" to positions on the keyboard like "left little finger left and down followed by striking the key left-low" (control-n). It needs quite some time to retrain your brain to use the keyboard neutral mapping, but soon it turns back to a (new) keyboard sensitive binding.
But that's not about which is better. That's about which is being used. What's being used is not necessarily what's better.