Sorry to shatter your dreams, but subversion is fundamentally unsuitable to a project like the Linux kernel.
Rik, actually, distributed repositories and inter-repository comminucation is a planned feature for SVN (though not for v1.0, IIRC).
And are there indeed BK repos, which push into the Linus's tree ? If not, all the hoopla about BK and its suitability for Linux (the kernel) development is just noise.
~velco
PS. FWIW, SVN is is a very advanced state. To paraphrase Roland McGrath - "We're way ahead of you. SVN has always been on the bleeding edge of not being useful for anything".
In other words, UL will become a reference for each member company to base their distros on as well as a reference and certification platform for developers and hardware vendors so they can guarantee their hardware/software works on any UL-based distro.
You mean that in addition to declared support for RedHat (the usual) proprietary software vendors will declare UL support and the respective packages would work in all the member companies' distros ? I can buy that.
OTOH, I couldn't care less for proprietary software vendors and certainly such kind of a move isn't going to enjoy high respect from the free software crowd.
I have serious doubts about the number of customers turned away from UL members' distros because proprietary software vendors mention RedHat. Anyone with a bit of clue would know that Linux (the kernel) is Linux (the kernel) and glibc is glibc no matter of the distro - and that's pretty much all as far as binary compatibility is concerned.
Having said that I seriously doubt in the success in a business model based on such a flawed presumption and I'd rather tend to maintain my previous opinion - these companies are desparately striving for survival.
Besides, IMHO, RedHat employs more Linux (the kernel), GCC and GLIBC developers than anyone else (and the top ones too). That certainly has positive effect on the quality of the distro as a whole.
Not, when RedHat is destroying free code by breaking KDE libraries as they want:-(
Do not expect everyone, including you and RedHat to have the same goals and visions about how a piece of software should look and feel like. RedHat puts (supposedly) in the first place ease of use and ease of transition from that other "OS" or from the other desktop env (no matter which). The good thing is that you disagree with their particular implementation or with the general direction you're free to keep (or develop) the alternative.
It is good, when someone can exercise their freedom, including the company, which is prolly the most free software friendly among other "linux" companies.
I really hope that UnitedLinux will gain ground.
Really ? I'd think they're closer to "destroying free code" in the light of their recent questionable behavior with respect to GPL.
Of course, it is just silly to think that any company or person is capable of "destroying free software". Not even capable of destroying a particular package.
A project can naturally die, but cannot be killed.
The hypocrisy of people complaining that P2P companies are stealing from affiliates (allowing them to steal from artists) or the fact that no one seemed to notice they were a hypocrite.
They aren't comparable.
One case involves permanently depriving someone of possession of something, while the other case does not.
One case involves fictitious(sp?) amount of "losses" stemming from the (false) assumption that there would be such and such amounts of purchases.
The other case involves redirecting the money after the fact of the purchase.
~velco
(The above "purchase" is in a broad sense, as some explicit action performed by a customer, which action results in a cash flow)
I've carefully read the EULA, but I do not find any explicit permission given to KAZAA to "2.4 Forge headers or otherwise manipulate identifiers in order to disguise the origin of any data transmitted to other users". On the contrary, the user is explicitly forbidden from doing so.
How can we lobby these Foundations to give grants to leading open source people like Larry Wall or Linus ? People who are much more than just good programmers but visionaries in their own right.
I can't see any indications in the article of KDE adopting Mono, i.e. the C# language and the.NET framework class libraries. They are developing bindings of the C# language to Qt, which is a horse of a waaaaaay different colo(u)r.
What is so "wrong" with American culture? Why everybody hates it?! If our culture can so easily break your own traditions from usual TV broadcasts then you should blame only yourself, not Americans. And if you don't like American Rationalism then welcome back to medieval age...
Nothing's wrong with American culture. Nor with the USA "culture", it's just that people outside USA don't call WWF, McDonalds and The Simpsons "culture".
AFAIK, -mfpmath=sse only makes use of the scalar fp instructions.
Yep. However, the important thing is that it does not use the fp stack from the i387 days, but the xmm registers.
Any idea when the vector ones will be supported? 3.2?
Hard to tell. The machine description for 3.1.1 (3.2 will be almost identical to 3.1.1) contains patterns for vector operations, but I don't think the compiler has the necessary array access dependence analysis and parallelizing phases in order to actually emit such patterns. There's a large number of SSE builtins though.
they go so far as to implement their own stack, which is absurd.
Nope, it is not. In fact is may have distinctive performance advatages. Consider this:
void quicksort (ELT *array, int low, int high);
That's three parameters to be passed in three registers or in three stack slots, compared to just two indices in the explicit stack. Then there's the return address, the caller-saved registers, the callee-saved registers and the stack alignment restrictions imposed by the architecture/ABI. It may happen that all of a sudden you are using, say, 16+ bytes for each recursive invocation instead of 8 for two integer indices. Now, take into account the additional cache and TLB misses imposed by the additional space needed and the additional control transfer during returns (I don't count calls, because the non-recursive version will have a loop).
Case in point: Check out the sorting chapter of Numerical Recipes, and you'll find that their "ultimate" sorting algorithm -- and hence the algorithm that a whole generation of FORTRAN coders think is the fastest -- is heapsort. Now, heapsort is a fine algorithm, but it has some significant disadvantages over quicksort (the algorithm used in the C/C++ standard library. well, almost, anyway.) Of course, you can't implement quicksort properly in FORTRAN because the language isn't recursive! So, I guess it makes sense that they skip over it in Numerical Recipes.
FWIW, both heapsort and quicksort have average complexity O(n log n), but heapsort has the same worst case complexity, whereas quicksort has O(n^2).
> > I believe that the GNU and at least a few > > commercial fortran compilers translate the code > > to C before it compiles.
Not true for GCC.
> the FORTRAN compiler is usually > much faster than the C compiler. I heard the > main reason is because of the C pointers. In > fortran, when a function receives two arrays as > input, the compiler can assume (it's part of the > language) that they are different arrays. In C, > for the same function, you are allowed to send > it the same array twice (it's called aliasing), > so because of that, the compiler is restricted > in the optimizations it can perform.
Yes. Note however that ISO/IEC 9899:1999 standard introduces (a) type-based aliasing rules and (b) the `restrict' keyword. The `restrict' keyword alone is sufficient to provide the same (non-) aliasing guaranties as FORTRAN.
> This kind > of ambiguities happen in other places too. That > being said, I HATE FORTRAN and for me, C++ when
Of course, C++ has _exactly_ the same aliasing problems as C, and is missing (yet) `restrict'.
> carefully coded can be nearly as fast (Of > course, I'm also using gcc which performance is > adequate but not more...).
Fair enough. BTW, have you tried -mfpmath=sse (for IA32, of course) ? Makes _real_ difference.
> Telsa Gwynne works on the GNOME Documentation
> Project. Besides, the board is not about coding,
> we need a well-balanced board of people with many
> different skills.
Cool, yeah. And now show me the people in the board
who care for anything other that their own
company profits, people who care for me, still a
GNOME user.
Note that this is systems benchmark, not a VM one.
There are a lot more different things in the two
kernels, than the VM. And note, that the server was
SMP, an area where FreeBSD folks admit "Linux is a
year ahead". It may turn out in the end that
actually the FreeBSD VM performs better, making
able the Big Lock BSD kernel catch up with more
fine graned Linux .
-velco
Lies, damned lies, statistics
> If the FBI want my public keys and they have a
> warrent, its all theirs,
Frankly, I give them my PUBLIC key without any
conditions ?
Just like to everyone else.
Are those guys going to outlaw
open source software ?
'Cause a backdoor can be seen from miles,
resulting in no security for those using open source, right ?
Slashdot Mirror
Sorry to shatter your dreams, but subversion is fundamentally unsuitable to a project like the Linux kernel.
Rik, actually, distributed repositories and inter-repository comminucation is a planned feature for SVN (though not for v1.0, IIRC).
And are there indeed BK repos, which push into the Linus's tree ? If not, all the hoopla about BK and its suitability for Linux (the kernel) development is just noise.
~velco
PS. FWIW, SVN is is a very advanced state. To paraphrase Roland McGrath - "We're way ahead of you. SVN has always been on the bleeding edge of not being useful for anything".
In other words, UL will become a reference for each member company to base their distros on as well as a reference and certification platform for developers and hardware vendors so they can guarantee their hardware/software works on any UL-based distro.
You mean that in addition to declared support for RedHat (the usual) proprietary software vendors will declare UL support and the respective packages would work in all the member companies' distros ? I can buy that.
OTOH, I couldn't care less for proprietary software vendors and certainly such kind of a move isn't going to enjoy high respect from the free software crowd.
I have serious doubts about the number of customers turned away from UL members' distros because proprietary software vendors mention RedHat. Anyone with a bit of clue would know that Linux (the kernel) is Linux (the kernel) and glibc is glibc no matter of the distro - and that's pretty much all as far as binary compatibility is concerned.
Having said that I seriously doubt in the success in a business model based on such a flawed presumption and I'd rather tend to maintain my previous opinion - these companies are desparately striving for survival.
Besides, IMHO, RedHat employs more Linux (the kernel), GCC and GLIBC developers than anyone else (and the top ones too). That certainly has positive effect on the quality of the distro as a whole.
~velco
I really hope that UnitedLinux will gain ground.
... I thought these companies are consolidating as a last resort to save themselves.
So do I. UnitedLinux is a group of Linux distributors that have chosen to work together to advance the LSB.
Hmm
~velco
Not, when RedHat is destroying free code by breaking KDE libraries as they want :-(
Do not expect everyone, including you and RedHat to have the same goals and visions about how a piece of software should look and feel like. RedHat puts (supposedly) in the first place ease of use and ease of transition from that other "OS" or from the other desktop env (no matter which). The good thing is that you disagree with their particular implementation or with the general direction you're free to keep (or develop) the alternative.
It is good, when someone can exercise their freedom, including the company, which is prolly the most free software friendly among other "linux" companies.
I really hope that UnitedLinux will gain ground.
Really ? I'd think they're closer to "destroying free code" in the light of their recent questionable behavior with respect to GPL.
Of course, it is just silly to think that any company or person is capable of "destroying free software". Not even capable of destroying a particular package.
A project can naturally die, but cannot be killed.
~velco
They aren't comparable.
One case involves permanently depriving someone of possession of something, while the other case does not.
One case involves fictitious(sp?) amount of "losses" stemming from the (false) assumption that there would be such and such amounts of purchases.
The other case involves redirecting the money after the fact of the purchase.
~velco
(The above "purchase" is in a broad sense, as some explicit action performed by a customer, which action results in a cash flow)
I've carefully read the EULA, but I do not find any explicit permission given to KAZAA to "2.4 Forge headers or otherwise manipulate identifiers in order to disguise the origin of any data transmitted to other users". On the contrary, the user is explicitly forbidden from doing so.
~velco
"Just For Fun" a vision ?
I can't see any indications in the article of KDE adopting Mono, i.e. the C# language and the .NET framework class libraries. They are developing bindings of the C# language to Qt, which is a horse of a waaaaaay different colo(u)r.
What is so "wrong" with American culture? Why everybody hates it?! If our culture can so easily break your own traditions from usual TV broadcasts then you should blame only yourself, not Americans. And if you don't like American Rationalism then welcome back to medieval age...
Nothing's wrong with American culture. Nor with the USA "culture", it's just that people outside USA don't call WWF, McDonalds and The Simpsons "culture".
~velco
Dike-Stra
Nope. In Dutch `ij' is pronounced more like `a' in `day', so it is 'Daykstra'.
~velco
AFAIK, -mfpmath=sse only makes use of the scalar fp instructions.
Yep. However, the important thing is that it does not use the fp stack from the i387 days, but the xmm registers.
Any idea when the vector ones will be supported? 3.2?
Hard to tell. The machine description for 3.1.1 (3.2 will be almost identical to 3.1.1) contains patterns for vector operations, but I don't think the compiler has the necessary array access dependence analysis and parallelizing phases in order to actually emit such patterns. There's a large number of SSE builtins though.
~velco
they go so far as to implement their own stack, which is absurd.
Nope, it is not. In fact is may have distinctive performance advatages. Consider this:
void quicksort (ELT *array, int low, int high);
That's three parameters to be passed in three registers or in three stack slots, compared to just two indices in the explicit stack. Then there's the return address, the caller-saved registers, the callee-saved registers and the stack alignment restrictions imposed by the architecture/ABI. It may happen that all of a sudden you are using, say, 16+ bytes for each recursive invocation instead of 8 for two integer indices. Now, take into account the additional cache and TLB misses imposed by the additional space needed and the additional control transfer during returns (I don't count calls, because the non-recursive version will have a loop).
~velco
~velco
> > I believe that the GNU and at least a few
> > commercial fortran compilers translate the code
> > to C before it compiles.
Not true for GCC.
> the FORTRAN compiler is usually
> much faster than the C compiler. I heard the
> main reason is because of the C pointers. In
> fortran, when a function receives two arrays as
> input, the compiler can assume (it's part of the
> language) that they are different arrays. In C,
> for the same function, you are allowed to send
> it the same array twice (it's called aliasing),
> so because of that, the compiler is restricted
> in the optimizations it can perform.
Yes. Note however that ISO/IEC 9899:1999 standard
introduces (a) type-based aliasing rules and (b)
the `restrict' keyword. The `restrict' keyword
alone is sufficient to provide the same (non-)
aliasing guaranties as FORTRAN.
> This kind
> of ambiguities happen in other places too. That
> being said, I HATE FORTRAN and for me, C++ when
Of course, C++ has _exactly_ the same aliasing
problems as C, and is missing (yet) `restrict'.
> carefully coded can be nearly as fast (Of
> course, I'm also using gcc which performance is
> adequate but not more...).
Fair enough. BTW, have you tried -mfpmath=sse
(for IA32, of course) ?
Makes _real_ difference.
~velco
> Why does everyone act like Microsoft is not supposed to try to make money?
Well, indeed.
And drug dealers are just trying to make some money too, what's wrong with that ?
Doom3 is allegedly written with OpenGL.
Free is a proper subset of OSS. As for the other thing,
Darwin (APL) is Open Source and not Free Software.
(hmm, they mau have changed APL though).
-velco
> Telsa Gwynne works on the GNOME Documentation
> Project. Besides, the board is not about coding,
> we need a well-balanced board of people with many
> different skills.
Cool, yeah. And now show me the people in the board
who care for anything other that their own
company profits, people who care for me, still a
GNOME user.
-velco
Note that this is systems benchmark, not a VM one.
There are a lot more different things in the two
kernels, than the VM. And note, that the server was
SMP, an area where FreeBSD folks admit "Linux is a
year ahead". It may turn out in the end that
actually the FreeBSD VM performs better, making
able the Big Lock BSD kernel catch up with more
fine graned Linux .
-velco
Lies, damned lies, statistics
So, Microsoft broke the law, fact established by two courts.
When you break the law you go to PRISON. Period.
Instead, the "punishment" is to vaguely ensure that they don't break the law anymore ?
Well, this is not true and just plain stupid.
> and missing out on all the other shared
> libraries because your project is in Java or
> Objective-C or Python etc.
Shared libaries are not in Java or C or any other language, they are BINARY. And, of course, every
language provides some means to call binary code.
-velco
It was the guy who invented rot13 ? Who did ? Caesar ? -velco
54 Yes, would favor
39 No, would not
7 Don't know
54 + 39 + 7 == 100
So where do they get those 72 %
> If the FBI want my public keys and they have a > warrent, its all theirs, Frankly, I give them my PUBLIC key without any conditions ? Just like to everyone else.
Are those guys going to outlaw open source software ? 'Cause a backdoor can be seen from miles, resulting in no security for those using open source, right ?