Do you want me to point you to the exact FAQ item ?
LGPL was invented to allow redistribution of code, possibly in binary-only form, redistribution meaning the one who produced the combined (*GPL + non-GPL) code ships the code to another company.
In-house use is not considered redistribution according to that FAQ item.
If you are not distributing the code, e.g. if you want a custom copy of Linux kernel built by yourself, and/or built by your company for internal use, you _can_ link - see GPL FAQ.
You have just admitted Java has no closures. Thank you. I do not do everything public; you might have noticed my mentioning of lexical variables.
Furthermore, I would rather even write
my $code_ref = sub{...};
rather than
sub code { ... }
to avoid name contention. "$code_ref" above is by no means public.
Anonymous export is the best way to avoid name space pollution/contention. I haven't mentioned dynamic vs static typing at all.
So, I guess, your comment is not quite unfair.
Good readability is a myth when it comes to hierarchical data structures. C++ fails miserably as well.
When you're in Perl, you can do practically everything in Perl, including user data input. When you are in Java, you'll typically use XML to do user data input.
...
If you want to read on an elegant OO model, you might find the info here:
Oh, and about "Inappropriate" - remember, "there is more than one way to do it".
Seriously, though, when one compares properly written Perl code with properly written Java code, the latter contains a lot of unnecessary things - to the extent I call it "imitation of boiling activity".
Furthermore, if you _really_ know Perl (its good part like anonymous references, closures, scoping, lexical variables, anonymous import, etc.) and if you know C++, you will be greatly disappointed by Java.
Linux will fail unless developers change their
attitude to documentation, specifically,
documentation related to drivers.
And it's time to stabilize kernel interface - I
have a friend who is an embedded Linux developer,
their stuff developed for 2.6.9 stopped working on
2.6.24.
I do not understand why the post is modded "funny".
Indeed, very fast SIMD libraries are coded in assembly.
I think even 'liboil' has some parts coded in assembly
I have carefully read what Linus and others wrote about practical impossibility to implelement stable kernel ABI and sounds to me like nonsense - to the extent I'd like to write a document which disproves their point.
If I ever do it, the document will be based on the ideas discussed in
The kernel developers' argument about different versions of compilers and different ways they map data is nonsense because drivers should be statically linked and not depend on any external library, they should be executable memory image.
You are both right and wrong.
Perl 4 was released before Python and Perl 4 did not have OO model.
Perl 5 was released well after Python (1997 ?) and Larry Wall now regrets about borrowing OO model from Python.
Do you want me to point you to the exact FAQ item ?
LGPL was invented to allow redistribution of code,
possibly in binary-only form, redistribution meaning the one who produced the combined (*GPL + non-GPL) code ships the code to another company.
In-house use is not considered redistribution according to that FAQ item.
The mandatory "does it run Linux ?" boils down to "do they provide enough documentation to write drivers for it ?".
I RTFA, but I didn't find an answer in it.
Actually, you are _very_ correct and should have gotten +5 moderation.
Just compile locally a copy of ZFS and link it with any GPL code.
As long as you do not distribute the binary, you are OK - GPL FAQ explicitly allows this.
And what does it have to do with Perl ?
And why not OCaml ? Nicely separated into both functional and imperative parts.
Has a lot of lazy evaluation stuff in libraries.
Has modifiable syntax/grammar.
Very efficient - number 2 after "C".
If you are not distributing the code, e.g. if you want a custom copy of Linux kernel built by yourself, and/or built by your company for internal use, you _can_ link - see GPL FAQ.
I haven't tried ZFS myself; license is not an
issue if you build kernel from source locally and do _not_ redistribute it in binary form.
You can, however, distribute that self-built kernel across computers on the same site.
This all is covered by GPL FAQ.
For some reason, Yahoo often yields better search results than Google.
You have just admitted Java has no closures. Thank you.
...
I do not do everything public; you might have noticed my mentioning of lexical variables.
Furthermore, I would rather even write
my $code_ref = sub{...};
rather than
sub code
{
}
to avoid name contention. "$code_ref" above is by no means public.
Anonymous export is the best way to avoid name space pollution/contention.
I haven't mentioned dynamic vs static typing at all.
So, I guess, your comment is not quite unfair.
Good readability is a myth when it comes to hierarchical data structures. C++ fails miserably as well.
When you're in Perl, you can do practically everything in Perl, including user data input.
When you are in Java, you'll typically use XML to do user data input.
...
If you want to read on an elegant OO model, you might find the info here:
http://search.cpan.org/~sartak/Moose-0.55/lib/Moose.pm
.
Oh, and about "Inappropriate" - remember, "there is more than one way to do it".
Seriously, though, when one compares properly written Perl code with properly written Java code, the latter contains a lot of unnecessary things - to the extent I call it "imitation of boiling activity".
Furthermore, if you _really_ know Perl (its good part like anonymous references, closures, scoping, lexical variables, anonymous import, etc.) and if you know C++, you will be greatly disappointed by Java.
The company that employs my friend is simply moving away from Linux - to Lynux - look it up.
Linux will fail unless developers change their attitude to documentation, specifically, documentation related to drivers. And it's time to stabilize kernel interface - I have a friend who is an embedded Linux developer, their stuff developed for 2.6.9 stopped working on 2.6.24.
I do not understand why the post is modded "funny". Indeed, very fast SIMD libraries are coded in assembly. I think even 'liboil' has some parts coded in assembly
I have carefully read what Linus and others wrote about practical impossibility
g _id=13588670
g _id=13609229
to implelement stable kernel ABI and sounds to me like nonsense - to the extent I'd
like to write a document which disproves their point.
If I ever do it, the document will be based on the ideas discussed in
debuggability of ALSA
thread I started. The thread started as
http://sourceforge.net/mailarchive/message.php?ms
, an ABI proposal of mine is
http://sourceforge.net/mailarchive/message.php?ms
.
The kernel developers' argument about different versions of compilers and
different ways they map data is nonsense because drivers should be statically
linked and not depend on any external library, they should be executable memory
image.