> "The obscure.ORG site claims to offer free
> services, but a registration is needed for
> downloading the software that apparently has
> been copied from the official MySQL.com
> website."
And?
If the mysql.com guys didn't want other people being able to distribute their code, they shouldn't have issued it under the GPL.
If they didn't want people to be able to modify their software, and distribute the modified versions, they shouldn't have issued it under the GPL.
If they didn't want to let other, possibly competing companies make money out of packaging and selling their software, they shouldn't have issued it under the GPL.
There is nothing, absolutely nothing, wrong with what mysql.org is doing with the mysql software. MySQL AB granted them those rights when they decided to release it under the GPL.
There is no ethical, legal or moral reason why they should not fork off a new code tree from the main distribution.
There is no ethical, legal or moral reason why they should not create a web site to distribute their version of the software, and to try to earn money from the product.
This isn't something going wrong, people - it's the GPL working EXACTLY AS IT'S MEANT TO.
As to the trademark issue, I think it's clearly against the spirit of Free Software to top other people using the name "mysql" if they excercise the rights you gave them under the GPL.
MySQL AB seem to have made a very bad judgement when they wen't GPL... they don't care about Free Software at all.
Yes. I like it a lot. If you set up your toolbar correctly it doesn't take up any more space either.
PageRank doesn't seem all that useful to me but the "Page Info" menu has some cool stuff in it, like "find reverse links" and a "similar pages" option that actually works.
The whole thing is very well done; the integration between the site you're viewing, the toolbar, and the google site is very well done. If you use google a lot (it's my home page) this is definitely worth having. I'll be keeping it.
"hard to learn, hard to use well and devillishly difficult to maintain".
All software sucks, and all programming languages suck. PERL sucks. Python sucks. C sucks. C++ sucks++. etc.
The one thing that is possibly different about PERL is that the guy in charge, who's view of the world is shaped by a polymath background, REALISES that his language sucks, and is trying to make it suck less.
For instance "TIMTOWTDI" might seem like a "sucks" thing to you. You might regard having multiple ways to express the same thing as something that makes a language harder.
But Larry Wall, as a linguist, would say it is a characteristic of all natural languages. In English, for instance, there are countless dozens of ways to rephrase "My silly aunt's accountancy course starts next week."
For instance,
"The accountancy course my silly aunt is taking starts next week".
"Next week my aunt's accountancy course starts. She's silly."
Which of these is correct? All of them. And none of them is more correct than the others.
My point is that language features like the ones Larry Wall has put into PERL (I'm thinking for instance of implicit variables), which some people regard as being bad things, are in fact honest and (for some people at least) helpful attempts to suck less.
And this ongoing quest to suck less, not just than the previous versions of PERL, but to suck less than "programming" in general will continue in PERL 6.
> Also, you are mixing RIPE general policy with
> host policy. RIPE is assuming this stance on
> all addresses. You have to justify anything
> above/31 by default with them. If you are a
> big ISP they may raise this so called
> assignment window but not by much. This is
> quite different compared to the US.
This isn't true. Most RIPE local registries have
assignment windows of at least/24, and mine was
/23. You don't need any explicit approval for
these, but you still need the documentation
because they randomly audit your decision making.
RIPE (The European allocation authority) has had
this policy for a few years now. You *can* get
space assigned for IP virtual hosts, but there's
a "special application procedure" in place meaning
you have to justfy each assignment and get approval from RIPE staff.
The fact is that the Host: header has been a part
of HTTP for a very long time now, and the number of HTTP clients which don't support it is trivially small - certainly not enough to justify the vast acrages of IP space it eats up. IP virtual hosting is an idea who's time has gone.
Building on the success of previous versions of Perl, with its famous "line noise as syntax" philosophy, Perl 6 is to borrow heavily from a certain other scripting language and introduce syntactically significant whitespace.
In keeping with the spirit of Perl, heavy use will be made of default variables in this new system. So for example, the commonly used "print" command will be replaced by:
And the almost-as-common "if" will become:
Instead of "foreach" it will be possible to use:
And lastly, any reference to "$_" or "($_)" can be replaced by:
So a typical Perl 6 program segment might look like this.
#!/usr/bin/perl
(@_){ { ; } }
Larry has expressed his gratitude to the Python developers for their initial work in this area.
> Maybe because binary works better for some things?
Yes, it does. Graphic images for instance, are usually best not formatted in ASCII:) But I don't think this is an example of one of those things.
> Maybe because a binary file is easier to edit from a program than a text file?
Making the software use text files is a little harder for the programmer, but only has to be done once.
Making the user edit binary files is very, very much harder, and if often impossible in practice. And it often has to be done over and over again in the life of a system. Why else do you think files like resolv.conf and inittab are human readable?
Anything that takes administrative control of your system away from you and gives it over to unreadable binary files and over-complex software (hello, RPM) is a Bad Thing (tm).
> it will even explain to you why some files have a "do not edit" header. But it's not because you can't edit'm manually.
Go on then, I'll bite.
Why do they have a "DO NOT EDIT" header if it's not because you can't edit them?
Sure, you can load them in to vi and make any changes you want. But next time you do anything even vaguely network related in yast, your changes will be lost. That's what I mean by "you can't edit them". And that's why the files say "DO NOT EDIT".
Of course, you could just never use yast again. That's pretty much what I do.
No I'm not. I'm absolutely 100% factually correct. The SuSe/etc/resolv.conf contains the line:
# PLEASE DO NOT EDIT THIS FILE
> The 'do not edit' is usually put in files which are edited by a process
Yes, that's right. That's what I'm complaining about. These files are designed to be edited by a system administrator. What's more, if you learn how to configure DNS by editing resolv.conf, that knowledge will stand you in good stead on BSD, Solaris, AIX, Dynix etc etc etc. Learning how to do it with yast will be of precisely no use to you.
I don't mind processes altering these files where appropriate; but if they're written in such a way that they can't cope with changes made by the system administrator, they are broken.
Because (for instance), it has an/etc/resolv.conf which does NOT contain the line: # PLEASE DO NOT EDIT THIS FILE..as in SuSe (and similar annoyances in RedHat). Anything that doesn't let you edit your own/etc files (or if you do, you can never ever run the distro's configuration tools ever again...) just plain sucks. Slackware forever!
He might not speak for everyone, but I certainly agree with him, and I would say that he does speak with authority and from experience.
He's not just a self-appointed Katz-like "spokesman for the hackers". ESR is a real honest-to-god open source programmer, with several significant contributions to the Linux kernel amongst other things.
2.4 will have SMP support which is so massively much better than previous versions that it will blow you away. The old SMP support was to some degree a hack; every time a CPU called a kernel routine the entire kernel was locked out for other CPUs.
The new code has completely rewritted the locking so that there is no longer a single global lock, but seperate discrete locks for each thing that needs them.
The impact of this, plus a few other IO related changes, should be that Linux will scale better than Solaris to large numbers of CPUs. Well, that's the theory anyway...
No,.com and.firm aren't countries. That's why they don't have country-code TLDs. They are so-called "generic TLDs" which are not associated with a geographic area..eu, on the other hand, would have to be geographic (Europe being a continent and all).
It's really quite simple. There are two ways a new domain can be added. Either because it's a generic TLD open to anyone (which EU wouldn't be) or because it's an ISO-3166 country code which hasn't been delegated. Which EU isn't.
The point is that under the current rules there is no avenue by which.eu could be delegated.
Slashdot Mirror
> services, but a registration is needed for
> downloading the software that apparently has
> been copied from the official MySQL.com
> website."
And?
If the mysql.com guys didn't want other people being able to distribute their code, they shouldn't have issued it under the GPL.
If they didn't want people to be able to modify their software, and distribute the modified versions, they shouldn't have issued it under the GPL.
If they didn't want to let other, possibly competing companies make money out of packaging and selling their software, they shouldn't have issued it under the GPL.
There is nothing, absolutely nothing, wrong with what mysql.org is doing with the mysql software. MySQL AB granted them those rights when they decided to release it under the GPL.
There is no ethical, legal or moral reason why they should not fork off a new code tree from the main distribution.
There is no ethical, legal or moral reason why they should not create a web site to distribute their version of the software, and to try to earn money from the product.
This isn't something going wrong, people - it's the GPL working EXACTLY AS IT'S MEANT TO.
As to the trademark issue, I think it's clearly against the spirit of Free Software to top other people using the name "mysql" if they excercise the rights you gave them under the GPL.
MySQL AB seem to have made a very bad judgement when they wen't GPL... they don't care about Free Software at all.
This is, of course, complete rubbish. Psion handhelds have shipped with Psiwin and a link cable for many years now, at no extra cost.
-rwxr-xr-x 1 root root 158740 May 1 1999 /usr/bin/pico /usr/bin/joe /usr/bin/jed /usr/bin/vim
-rwxr-xr-x 1 root root 180484 May 1 1999
-rwxr-xr-x 1 root root 256972 May 1 1999
-rwxr-xr-x 1 root root 503832 May 1 1999
Any of those small enough? How about
-rwxr-xr-x 1 root root 47656 Apr 30 1999 /usr/bin/ed
PageRank doesn't seem all that useful to me but the "Page Info" menu has some cool stuff in it, like "find reverse links" and a "similar pages" option that actually works.
The whole thing is very well done; the integration between the site you're viewing, the toolbar, and the google site is very well done. If you use google a lot (it's my home page) this is definitely worth having. I'll be keeping it.
Wrong pollutant. The most significant greenhouse gas, by an order of magnitude, is water vapour. So stop breathing out!
"hard to learn, hard to use well and devillishly difficult to maintain".
All software sucks, and all programming languages suck. PERL sucks. Python sucks. C sucks. C++ sucks++. etc.
The one thing that is possibly different about PERL is that the guy in charge, who's view of the world is shaped by a polymath background, REALISES that his language sucks, and is trying to make it suck less.
For instance "TIMTOWTDI" might seem like a "sucks" thing to you. You might regard having multiple ways to express the same thing as something that makes a language harder.
But Larry Wall, as a linguist, would say it is a characteristic of all natural languages. In English, for instance, there are countless dozens of ways to rephrase "My silly aunt's accountancy course starts next week."
For instance,
"The accountancy course my silly aunt is taking starts next week".
"Next week my aunt's accountancy course starts. She's silly."
Which of these is correct? All of them. And none of them is more correct than the others.
My point is that language features like the ones Larry Wall has put into PERL (I'm thinking for instance of implicit variables), which some people regard as being bad things, are in fact honest and (for some people at least) helpful attempts to suck less.
And this ongoing quest to suck less, not just than the previous versions of PERL, but to suck less than "programming" in general will continue in PERL 6.
M is, of course, a programming language which makes PERL look inherently readable:
f p=2,3:2 s q=1 x "f f=3:2 q:f*f>p!'q s q=p#f" w:q p,?$x\8+1*8
My experience of M is in a financial environment where it is also popular for investment management systems.
> Also, you are mixing RIPE general policy with /31 by default with them. If you are a
/24, and mine was
> host policy. RIPE is assuming this stance on
> all addresses. You have to justify anything
> above
> big ISP they may raise this so called
> assignment window but not by much. This is
> quite different compared to the US.
This isn't true. Most RIPE local registries have
assignment windows of at least
/23. You don't need any explicit approval for
these, but you still need the documentation
because they randomly audit your decision making.
Andrew
The fact is that the Host: header has been a part of HTTP for a very long time now, and the number of HTTP clients which don't support it is trivially small - certainly not enough to justify the vast acrages of IP space it eats up. IP virtual hosting is an idea who's time has gone.
In keeping with the spirit of Perl, heavy use will be made of default variables in this new system. So for example, the commonly used "print" command will be replaced by:
And the almost-as-common "if" will become:
Instead of "foreach" it will be possible to use:
And lastly, any reference to "$_" or "($_)" can be replaced by:
So a typical Perl 6 program segment might look like this.
#!/usr/bin/perl
;
(@_){
{
}
}
Larry has expressed his gratitude to the Python developers for their initial work in this area.
Yes, it does. Graphic images for instance, are usually best not formatted in ASCII :) But I don't think this is an example of one of those things.
> Maybe because a binary file is easier to edit from a program than a text file?
Making the software use text files is a little harder for the programmer, but only has to be done once.
Making the user edit binary files is very, very much harder, and if often impossible in practice. And it often has to be done over and over again in the life of a system. Why else do you think files like resolv.conf and inittab are human readable?
Anything that takes administrative control of your system away from you and gives it over to unreadable binary files and over-complex software (hello, RPM) is a Bad Thing (tm).
Go on then, I'll bite.
Why do they have a "DO NOT EDIT" header if it's not because you can't edit them?
Sure, you can load them in to vi and make any changes you want. But next time you do anything even vaguely network related in yast, your changes will be lost. That's what I mean by "you can't edit them". And that's why the files say "DO NOT EDIT".
Of course, you could just never use yast again. That's pretty much what I do.
No I'm not. I'm absolutely 100% factually correct. The SuSe /etc/resolv.conf contains the line:
# PLEASE DO NOT EDIT THIS FILE
> The 'do not edit' is usually put in files which are edited by a process
Yes, that's right. That's what I'm complaining about. These files are designed to be edited by a system administrator. What's more, if you learn how to configure DNS by editing resolv.conf, that knowledge will stand you in good stead on BSD, Solaris, AIX, Dynix etc etc etc. Learning how to do it with yast will be of precisely no use to you.
I don't mind processes altering these files where appropriate; but if they're written in such a way that they can't cope with changes made by the system administrator, they are broken.
Because (for instance), it has an /etc/resolv.conf which does NOT contain the line: # PLEASE DO NOT EDIT THIS FILE ..as in SuSe (and similar annoyances in RedHat). Anything that doesn't let you edit your own /etc files (or if you do, you can never ever run the distro's configuration tools ever again...) just plain sucks. Slackware forever!
Oh, well that's conclusive. I don't think.
For a start, there's CML2, which looks likely to be what gets run when you type "make config" in future. This is entirely an ESR work.
That is a worry. An even bigger worry is that they might try to help it!
honest-to-bob then!
He's not just a self-appointed Katz-like "spokesman for the hackers". ESR is a real honest-to-god open source programmer, with several significant contributions to the Linux kernel amongst other things.
The new code has completely rewritted the locking so that there is no longer a single global lock, but seperate discrete locks for each thing that needs them.
The impact of this, plus a few other IO related changes, should be that Linux will scale better than Solaris to large numbers of CPUs. Well, that's the theory anyway...
No.
> /var has to be on the root partition
No.
> What is normally in var (logs and such) is in /usr/adm
vi /etc/syslogd.conf
> Most sysadmin tasks (such as adding a user) should not be done on the command line
Oh really? Seems to work here.
> You should use their menu system because it twiddels with bits on some internal-not-text database
Nonsense.
Dynix is a great OS. Sure, you need to spend a few hours installing bash, a decent sendmail, etc etc but that's no different from Solaris or AIX.
You typed slahsdot.org by mistake. Simple as that.
Sadly, the chance for Motif to make good is long gone. It is a painfully old fashioned library. It belongs to the past, not the future.
I suppose open sourcing it is at least a dignified retirement...
I think you need to read over what you wrote here.
If it doesn't cover some countries in the area, that's evidence that it is geographic.
> What ccTLD would you suggest for the EU > parliament? How about .eu.int. Oh wait a minute. That's what they already have!
It's really quite simple. There are two ways a new domain can be added. Either because it's a generic TLD open to anyone (which EU wouldn't be) or because it's an ISO-3166 country code which hasn't been delegated. Which EU isn't.
The point is that under the current rules there is no avenue by which .eu could be delegated.