> > Python is used pretty much across the board, much more across the board than Perl.
> Who is he kidding?
I think you've taken this up wrong. I think he
meant that Python is more suitable for a wider
variety of applications than Perl, which sometimes
shows its origins as a string processing language.
Don't forget that windows.dlls and unix.so
are quite different beasts, despite doing roughly
the same thing.
Windows dlls are not fully PIC (position
independent code) so they are smaller than an
equavalent unix one. OTOH a unix.so can always
be shared between processes, but a windows one
may not be able to unless it can map to the exact
same address in both processes!
Unix is better if you have many processes using
the same lib, and windows wins if there is only
one copy being used.
It's a standalone http mp3 server. In one python script. It sends.m3u to your player so that the mp3s are streamed. It can also shuffle and play recursively.
Highly recommended.
Stephen.
(for the other end of things 'jack' is an excellent ripper/encoder btw.)
Re:Substandard C++ compiler, libraries, etc...
on
Why Develop On Linux?
·
· Score: 1
>Thread support in Linux is robust and follows the POSIX standard.
Heh, not really. They follow it closely, but deliberately not exactly. See the linux-kernel mailing list.
As for the DLL issue, the way windows does it is quite a bit better if the DLL is only used once, since the code can be smaller (non PIC). UNIX wins if the DLL must be loaded several times.
This is one of the reasons why windows mozilla components are smaller than their unix counterparts.
Actually I wasn't talking about binary level compatibility. I suggested the possibility of a binary compatibility _layer_.
That is: use a set of functions to read values from kernel structures instead of accessing the values directly. One cause of problems occur when structure sizes or layouts change. Of course, if the interface changes there might not be a lot you can do.
Looking at some previous posts it seems that aureal have taken this approach - a binary driver and open source glue between the kernel and driver.
I suggest a standard 'glue layer' could be a good idea.
This is great news since it makes linux more respectable as a gaming platform.
It does raise the issue of kernel versions (again) Modules compiled for one version of the kernel won't necessarily work for other versions. I can imagine that it could be a nightmare for a company to support multiple versions of a binary-only driver. Linus has repeatedly said (quite rightly from an OS standpoint) that he makes no guarantees of binary compatibility between versions. He will work hard to ensure source compatibility though.
Yes, binary only sucks but giving source/register level information can give away IP to compeditors.
Perhaps an optional binary compatibility layer should be introduced into the kernel. It may not be quite as fast as a 'native' version, but hey thats the price you pay for a binary only multiple version driver.
Dont forget the Streaming Simd Extensions (SSE, also known as KNI) which is like MMX only for floating point. Probably much more useful than MMX too, given the current 3d mania.
a) there are people who could really use the information in the books, but can't afford them. (poor students?) These people would have to make do with other possibly worse docs. The publishers win because these people will gain respect for the publisher if the book is any good.
b) people with cash to spend can make better choices. For instance if I came across an online book which I thought was relevant and good, I would be more inclined to buy it. Even if it had nothing new to me, I still may buy it for my co-workers.
There really is nothing like a bound book. Computer professionals desks are swamped in reams of a4 printouts. Does anybody actually print the things out instead of reading online?
It dosen't seem like this is a big deal to me. This allows remote running of windows apps in a similar way to X (though not as good I'll warrant since X was designed for networking from the ground up)
For the home user though its pretty useless. It sounds like you'd have to have a fairly beefy application server to make it work. And for games it's next to useless.
It seems to me that some of the biggest improvements in Wine have been in getting games to work.
Slashdot Mirror
One i've used for over a year is
the gtk+ metal theme with the
Latem sawfish theme.
It's pretty and very usable.
stephen.,
Which 'barrier' was that?
Python has no ++ nor -- operators.
v2.0 introduced +=, *= et al for conciseness
and optimisation.
Guido has publicly stated that ++ and -- won't
go into python.
Stephen.
> > Python is used pretty much across the board, much more across the board than Perl.
> Who is he kidding?
I think you've taken this up wrong. I think he
meant that Python is more suitable for a wider
variety of applications than Perl, which sometimes
shows its origins as a string processing language.
Don't forget that windows
are quite different beasts, despite doing roughly
the same thing.
Windows dlls are not fully PIC (position
independent code) so they are smaller than an
equavalent unix one. OTOH a unix
be shared between processes, but a windows one
may not be able to unless it can map to the exact
same address in both processes!
Unix is better if you have many processes using
the same lib, and windows wins if there is only
one copy being used.
Stephen.
http://www.lyra.org/greg/edna
It's a standalone http mp3 server. In one
python script. It sends
so that the mp3s are streamed. It can also
shuffle and play recursively.
Highly recommended.
Stephen.
(for the other end of things 'jack' is an
excellent ripper/encoder btw.)
>Thread support in Linux is robust and follows the POSIX standard.
Heh, not really. They follow it closely, but deliberately not exactly. See the linux-kernel mailing list.
As for the DLL issue, the way windows does it is quite a bit better if the DLL is only used once, since the code can be smaller (non PIC). UNIX wins if the DLL must be loaded several times.
This is one of the reasons why windows mozilla components are smaller than their unix counterparts.
Stephen.
Simply ecause each unix command should do
one thing and do it well.
If it really annoys you it is trivial to
write aliases:
alias mygzip='tar cvfz'
alias mygunzip='tar xvfz'
alias mybzip2='tar cvfI'
alias mybunzip2='tar xvfI'
And while you're at it you can call
your files
Steve.
Actually I wasn't talking about binary level
compatibility. I suggested the possibility
of a binary compatibility _layer_.
That is: use a set of functions to read values
from kernel structures instead of accessing
the values directly. One cause of problems
occur when structure sizes or layouts change.
Of course, if the interface changes there might
not be a lot you can do.
Looking at some previous posts it seems that
aureal have taken this approach - a binary
driver and open source glue between the kernel
and driver.
I suggest a standard 'glue layer' could be a
good idea.
Steve.
This is great news since it makes linux more
respectable as a gaming platform.
It does raise the issue of kernel versions (again)
Modules compiled for one version of the kernel
won't necessarily work for other versions. I can
imagine that it could be a nightmare for a company
to support multiple versions of a binary-only
driver. Linus has repeatedly said (quite rightly
from an OS standpoint) that he makes no guarantees
of binary compatibility between versions. He
will work hard to ensure source compatibility
though.
Yes, binary only sucks but giving source/register
level information can give away IP to compeditors.
Perhaps an optional binary compatibility layer
should be introduced into the kernel. It may not
be quite as fast as a 'native' version, but hey
thats the price you pay for a binary only multiple
version driver.
Steve.
> Pentium III - Umm, just plain faster?
Dont forget the Streaming Simd Extensions
(SSE, also known as KNI) which is like MMX
only for floating point. Probably much more
useful than MMX too, given the current 3d
mania.
Steve.
I really like this approach because
a) there are people who could really use the
information in the books, but can't afford them.
(poor students?) These people would have to make
do with other possibly worse docs. The publishers
win because these people will gain respect
for the publisher if the book is any good.
b) people with cash to spend can make better
choices. For instance if I came across an online
book which I thought was relevant and good, I
would be more inclined to buy it. Even if it
had nothing new to me, I still may buy it for
my co-workers.
There really is nothing like a bound book.
Computer professionals desks are swamped in
reams of a4 printouts. Does anybody actually
print the things out instead of reading online?
STeve.
It dosen't seem like this is a big deal to me.
This allows remote running of windows apps
in a similar way to X (though not as good I'll
warrant since X was designed for networking from
the ground up)
For the home user though its pretty useless. It
sounds like you'd have to have a fairly beefy
application server to make it work. And for games
it's next to useless.
It seems to me that some of the biggest
improvements in Wine have been in getting
games to work.
Steve.
Unix(tm) looses the rumor to be difficult to use and to be just something for specialists and freaks.
FREAKS! Ha! Does nobody else have the image
of elephant man telnetting to the bearded
ladys box in a draughty old tent?
If it was /just/ glide then it's no big deal.
But from the fact that opengl can be
implemented as a thin(ish) layer over glide
which makes it wa-hey cool for voodoo3
owners.
As one previous poster mentioned, it would
be great if 3dfx would release stuff which would
allow the older voodoo cards to work too.