Looking for LAME
Rowland McDonnell
I've had a look out there in Webland, trying to figure out what to get
to encode mp3s using LAME.
And I'm all confused at the range of stuff out there. How is one to
choose?
What do people here like by way of LAME encoders on MacOS X?
(Core2Duo iMac, 10.6.2)
Rowland.
--
Remove the animal for email address: rowland....@dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
chris
> So I am.
>
> I've had a look out there in Webland, trying to figure out what to get
> to encode mp3s using LAME.
>
> And I'm all confused at the range of stuff out there. How is one to
> choose?
There's only one LAME:
http://lame.sourceforge.net/download.php
And like all good open source projects you have to download and compile
it yourself. On the Mac you're probably better off installing it via
Fink or MacPorts.
> What do people here like by way of LAME encoders on MacOS X?
Lame is a commandline only tool, but there may be GUI tools for the Mac
which use lame as the backend encoder.
Rowland McDonnell
> Rowland McDonnell wrote:
> > So I am.
> >
> > I've had a look out there in Webland, trying to figure out what to get
> > to encode mp3s using LAME.
> >
> > And I'm all confused at the range of stuff out there. How is one to
> > choose?
>
> There's only one LAME:
> http://lame.sourceforge.net/download.php
>
> And like all good open source projects you have to download and compile
> it yourself.
One way of spotting a good open source projects is the fact that it's
got precompiled binaries available for all common platforms.
An open source project that does not supply precompiled binaries is for
geeks only and is therefore almost certainly a bad open source project.
>On the Mac you're probably better off installing it via
> Fink or MacPorts.
I'm wondering what the best precompiled version to use might be.
I've looked at Fink and MacPorts, and I don't trust either of 'em.
> > What do people here like by way of LAME encoders on MacOS X?
>
> Lame is a commandline only tool, but there may be GUI tools for the Mac
> which use lame as the backend encoder.
There are many. That's what I was asking about, really.
James Dore
VLC or Handbrake should be able to use LAME to encode to MP3, if my
cursory reading of their respective sites is anything to go by.
<http://www.videolan.org> and <http://handbrake.fr>
Cheers,
--
James Dore
New College IT Officer
james.dore@new / it-support@new
chris
> chris <ithi...@gmail.com> wrote:
>
>> Rowland McDonnell wrote:
>>> So I am.
>>>
>>> I've had a look out there in Webland, trying to figure out what to get
>>> to encode mp3s using LAME.
>>>
>>> And I'm all confused at the range of stuff out there. How is one to
>>> choose?
>> There's only one LAME:
>> http://lame.sourceforge.net/download.php
>>
>> And like all good open source projects you have to download and compile
>> it yourself.
>
> One way of spotting a good open source projects is the fact that it's
> got precompiled binaries available for all common platforms.
Producing binaries for all common platforms requires the availability of
all common platforms to the project developer(s). This is not a given as
most OSS projects don't have the funds to supply the platforms for the
compilation. Hence why you, the user, are given the tools to do what you
want with the project (i.e. the source code).
> An open source project that does not supply precompiled binaries is for
> geeks only and is therefore almost certainly a bad open source project.
It's not bad, just not for the lazy.
>> On the Mac you're probably better off installing it via
>> Fink or MacPorts.
>
> I'm wondering what the best precompiled version to use might be.
>
> I've looked at Fink and MacPorts, and I don't trust either of 'em.
Then LAME's not what you want.
Doesn't iTunes have the option to encode mp3s?
<Looks>
Yes it does.
John Hill
> So I am.
>
> I've had a look out there in Webland, trying to figure out what to get
> to encode mp3s using LAME.
>
> And I'm all confused at the range of stuff out there. How is one to
> choose?
>
> What do people here like by way of LAME encoders on MacOS X?
>
> (Core2Duo iMac, 10.6.2)
>
> Rowland.
Audacity? or is that overkill? <http://audacity.sourceforge.net/>
John.
--
Please reply to john at yclept dot wanadoo dot co dot uk.
Adrian C
>
> One way of spotting a good open source projects is the fact that it's
> got precompiled binaries available for all common platforms.
Because of legal problems, LAME is specifically not made available by
the developers precompiled.
--
Adrian C
Rowland McDonnell
> Rowland McDonnell wrote:
>
> > chris <ithi...@gmail.com> wrote:
> >
> >> Rowland McDonnell wrote:
[snip]
> >> On the Mac you're probably better off installing it via
> >> Fink or MacPorts.
> >
> > I'm wondering what the best precompiled version to use might be.
> >
> > I've looked at Fink and MacPorts, and I don't trust either of 'em.
> >
> >> > What do people here like by way of LAME encoders on MacOS X?
> >>
> >> Lame is a commandline only tool, but there may be GUI tools for the Mac
> >> which use lame as the backend encoder.
> >
> > There are many. That's what I was asking about, really.
>
> VLC or Handbrake should be able to use LAME to encode to MP3, if my
> cursory reading of their respective sites is anything to go by.
>
> <http://www.videolan.org> and <http://handbrake.fr>
VLC? Encoding? No, I don't think I'll try using it for that. I can
get VLC to play files that exist on a mounted disc.
I've tried using VLC's other abilities in the past and I have absolutely
no intention of engaging in that sort of masochism again. It's up to
v1.whatever now and they've still not even got antialiasing working
properly.
Handbrake, though - hmm. It's GUI. Odd - seems that the programmer
hasn't heard of universal binaries. Okay. Got it.
Erm, can you suggest how I might use it to convert audio files to mp3
using LAME?
I don't quite get the UI, you see. Yes, I've read rather a lot of the
documentation but as usual I can't start making sense out of it :-(
Same old story - too many assumptions made about what the user already
knows. Well, I don't, so I'm stuck on the starting blocks.
Rowland McDonnell
> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
>
> >An open source project that does not supply precompiled binaries is for
> >geeks only and is therefore almost certainly a bad open source project.
>
> Not bad.
I think so.
> Just not what you want.
Just not useful for anyone at all, except for the tiny minority of
computer users who are `in the know' about the required development
tools which enable them to compile and use this software.
The aim is to deny most of us that ability, so that we can be exploited
by those who do.
Since the aim of providing inaccessible development tools is to deny
access like that, I'll stick with the idea that it's bad any time a
software project fails to provide precompiled binaries, because it's
just a way to deny access to software. And I don't like that.
Rowland McDonnell
> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
>
> >So I am.
> >
> >I've had a look out there in Webland, trying to figure out what to get
> >to encode mp3s using LAME.
> >
> >And I'm all confused at the range of stuff out there. How is one to
> >choose?
> >
> >What do people here like by way of LAME encoders on MacOS X?
>
> FFmpeg
>
> svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
Umm - what does that mean?
>http://sourceforge.net/projects/lame/files/lame/3.98.2/lame-398-2.tar.g
z/download
Righto. Ta. Compile-it-yourself command line stuff, yes?
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > So I am.
> >
> > I've had a look out there in Webland, trying to figure out what to get
> > to encode mp3s using LAME.
> >
> > And I'm all confused at the range of stuff out there. How is one to
> > choose?
> >
> > What do people here like by way of LAME encoders on MacOS X?
> >
> > (Core2Duo iMac, 10.6.2)
> >
> > Rowland.
>
> Audacity? or is that overkill? <http://audacity.sourceforge.net/>
Not overkill so much as `you've got to be kidding'. The most recent
stable release was for MacOS X 10.1. It's semi-operational with a
really /really/ bad UI and worse documentation[1]. The people behind
Audacity aren't providing anything I can use.
Yes, I have looked - and it doesn't look like it'd be suitable for
someone interested in doing batch conversion jobs even if it was
slightly more usable.
Cheers,
Rowland.
[1] They've put the usual excuse for their creative masturbation up on
their Website:
"Because it is a work in progress and does not yet come with complete
documentation or translations into different languages, it is
recommended for more advanced users."
i.e., we don't give a shit about whether anyone can actually use this
software, we're just wankers having a good old wank.
Rowland McDonnell
Ah! Righto.
Umm.
What legal problems?
Rowland McDonnell
> Rowland McDonnell wrote:
> > chris <ithi...@gmail.com> wrote:
> >
> >> Rowland McDonnell wrote:
> >>> So I am.
> >>>
> >>> I've had a look out there in Webland, trying to figure out what to get
> >>> to encode mp3s using LAME.
> >>>
> >>> And I'm all confused at the range of stuff out there. How is one to
> >>> choose?
> >> There's only one LAME:
> >> http://lame.sourceforge.net/download.php
> >>
> >> And like all good open source projects you have to download and compile
> >> it yourself.
> >
> > One way of spotting a good open source projects is the fact that it's
> > got precompiled binaries available for all common platforms.
>
> Producing binaries for all common platforms requires the availability of
> all common platforms to the project developer(s).
I know what's needed.
> This is not a given as
> most OSS projects don't have the funds to supply the platforms for the
> compilation.
There's no need to provide special funds as you dishonestly suggest.
All open source software projects have within them access to the
required development tools on all the common PC platforms, and so
pre-compiled binaries are quick cheap and easy to provide if only the
programmers could be bothered to do so.
But they don't want to do it because it would let people who are not of
the aristocracy use their software - the *reason* for refusing to
provide precompiled binaries is to ensure that only software developers
(a tiny minority) can use the software.
They want to deny the use of their software to most people - don't ask
me why, but it's what they're up to.
> Hence why you, the user, are given the tools to do what you
> want with the project (i.e. the source code).
Hence why me, what you call the user, is not a user of any software
which is supplied as source code (except for LaTeX stuff) since it's
impossible for me to learn how to compile it - as is the case with
almost all computer users.
> > An open source project that does not supply precompiled binaries is for
> > geeks only and is therefore almost certainly a bad open source project.
>
> It's not bad, just not for the lazy.
That's extremely insulting of you.
Why be personally abusive like that?
Why not admit the reality, and it's got nothing to do with laziness and
everything to do with the fact that most people simply can't learn to
use the tools required to compile a binary?
I can't do it, and I'm somone who's pretty technically competent and
used to be able to program computers back when it was possible for me to
learn how.
I've even built on - out of chips, to my own personal design, not just
plugging pre-designed pre-tested modules all designed to work together
when fitted into a standard commercial chassis. Which is what people
mean by `design and build a computer' these days.
> >> On the Mac you're probably better off installing it via
> >> Fink or MacPorts.
> >
> > I'm wondering what the best precompiled version to use might be.
> >
> > I've looked at Fink and MacPorts, and I don't trust either of 'em.
>
> Then LAME's not what you want.
I want to use the LAME code for encoding mp3s.
I've written that - I'm sure it's what I want.
If you think otherwise, then you are wrong.
> Doesn't iTunes have the option to encode mp3s?
> <Looks>
> Yes it does.
Does iTunes have the option to encode mp3s using LAME?
<looks>
No it does not.
R
> R <me...@privacy.net> wrote:
> >http://sourceforge.net/projects/lame/files/lame/3.98.2/lame-398-2.tar.g
> z/download
>
> Righto. Ta. Compile-it-yourself command line stuff, yes?
Yes. It's not difficult and doesn't take long (I timed it at 32 seconds
to extract the archive, configure, make (compile, etc.) and install).
The commands used:
tar xf lame-398-2.tar.gz
cd lame-398-2
./configure --prefix=/usr/local
make -j 8 install
Voil�! lame ready to use.
John Hill
Fair enough.
I agree that the interface and documentation are something else again
:-(
But the current "beta" (Audacity � 1.3.10-alpha-Sep 14 2009 (Unicode))
is stable - even under Snow Leopard - and I have now used it with a USB
deck to transcribe well over a hundred 78s, EPs and LPs...
James Dore
<real-addr...@flur.bltigibbet.invalid> wrote:
> R <me...@privacy.net> wrote:
>
>> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
>>
>> >An open source project that does not supply precompiled binaries is for
>> >geeks only and is therefore almost certainly a bad open source project.
>>
>> Not bad.
>
> I think so.
>
>> Just not what you want.
>
> Just not useful for anyone at all, except for the tiny minority of
> computer users who are `in the know' about the required development
> tools which enable them to compile and use this software.
That's a bit harsh. My experience with MacPorts is that it hides most of
that for you. You need to download Apple's Developer tools (or install it
from your Mac OS X media) but the procedure is not opaque. I don't know
one end of XCode from the other, but I managed to install it (run the
installer like every other .app) and get MacPorts running with little
practical knowledge of the Developer tools. I haven't had to run
makefiles, or ./configure or whatever else it is that MacPorts does (it
all flashes by too quickly for me to see, although I could probably look
in the logs if I could be arsed).
Things were made more simple again when I got PortAuthority (see
<http://codebykevin.com> ), which provides a GUI front end for MacPorts,
and makes it more accessible.
It gave me working copies of nmap and wireshark long before decent OS X
binaries were available; and there are plenty of other useful goodies in
the Audio section.
> The aim is to deny most of us that ability, so that we can be exploited
> by those who do.
Sure - it's like maintaining your car. You can do it (and become less
exploited by the car dealerships) if you look into it.
> Since the aim of providing inaccessible development tools is to deny
> access like that, I'll stick with the idea that it's bad any time a
> software project fails to provide precompiled binaries, because it's
> just a way to deny access to software. And I don't like that.
You could also look at it as providing access to software that wouldn't
otherwise exist for a particular platform. Developers may not have time to
build binaries for platforms x, y, and z, but providing the source code
allows binaries to be generated for platforms x, y, z, and a, b, c, and d
as well.
Mind you, no-one is forcing you to use it, but you're just cutting off a
potentially very useful resource.
Phil Taylor
<ne...@erewhon.invalid> wrote:
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > So I am.
> >
> > I've had a look out there in Webland, trying to figure out what to get
> > to encode mp3s using LAME.
> >
> > And I'm all confused at the range of stuff out there. How is one to
> > choose?
> >
> > What do people here like by way of LAME encoders on MacOS X?
> >
> > (Core2Duo iMac, 10.6.2)
> >
> > Rowland.
>
> Audacity? or is that overkill? <http://audacity.sourceforge.net/>
That would be my suggestion too. Older versions of Audacity used to
require the separate installation of LAME. but now I think the code is
built in. It will open most audio files (aiff, wave, au, ogg, mp3
etc.) and export them. Does a good job on mp3s too.
Phil Taylor
Woody
> chris <ithi...@gmail.com> wrote:
> > Producing binaries for all common platforms requires the availability of
> > all common platforms to the project developer(s).
>
> I know what's needed.
>
> > This is not a given as
> > most OSS projects don't have the funds to supply the platforms for the
> > compilation.
>
> There's no need to provide special funds as you dishonestly suggest.
>
> All open source software projects have within them access to the
> required development tools on all the common PC platforms, and so
> pre-compiled binaries are quick cheap and easy to provide if only the
> programmers could be bothered to do so.
How do they? Most open source software projects are one or two people,
and they certainly can't afford all the platforms. And why should they
pay money to provide you with something for free?
In which case you generally get linux and windows, as they are the
common or free platforms.
> But they don't want to do it because it would let people who are not of
> the aristocracy use their software - the *reason* for refusing to
> provide precompiled binaries is to ensure that only software developers
> (a tiny minority) can use the software.
That is complete bollocks.
> > Hence why you, the user, are given the tools to do what you
> > want with the project (i.e. the source code).
>
> Hence why me, what you call the user, is not a user of any software
> which is supplied as source code (except for LaTeX stuff) since it's
> impossible for me to learn how to compile it - as is the case with
> almost all computer users.
As someone else pointed out - it is 5 lines you have to type.
> > > I've looked at Fink and MacPorts, and I don't trust either of 'em.
> >
> > Then LAME's not what you want.
>
> I want to use the LAME code for encoding mp3s.
>
> I've written that - I'm sure it's what I want.
>
> If you think otherwise, then you are wrong.
So what is the problem, someone has told you where the LAME code is, so
use it as you are sure that is what you want.
> > Doesn't iTunes have the option to encode mp3s?
> > <Looks>
> > Yes it does.
>
> Does iTunes have the option to encode mp3s using LAME?
>
> <looks>
>
> No it does not.
Well, if you wont use the tools you are provided with, you can't be
bothered to work out how to make it yourself, you aren't prepared to
download audacity which can download it itself and you can't type 'OSX
binary LAME' in google to find it, what exactly do you want? Just a
whinge that you have to do something yourself?
--
Woody
zoara
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > chris <ithi...@gmail.com> wrote:
> > > This is not a given as
> > > most OSS projects don't have the funds to supply the platforms for
> > > the
> > > compilation.
> >
> > There's no need to provide special funds as you dishonestly suggest.
> >
> > All open source software projects have within them access to the
> > required development tools on all the common PC platforms, and so
> > pre-compiled binaries are quick cheap and easy to provide if only
> > the
> > programmers could be bothered to do so.
>
> How do they? Most open source software projects are one or two people,
> and they certainly can't afford all the platforms. And why should they
> pay money to provide you with something for free?
Is Rowland perhaps suggesting that the developers precompile for
platforms they don't have access to?
I'm sure that's possible in a number of cases, though it's exceptionally
foolhardy.
-zoara-
--
email: nettid1 at fastmail dot fm
Rowland McDonnell
> Woody <use...@alienrat.co.uk> wrote:
> > Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> >
> > > chris <ithi...@gmail.com> wrote:
>
> > > > This is not a given as
> > > > most OSS projects don't have the funds to supply the platforms for
> > > > the
> > > > compilation.
> > >
> > > There's no need to provide special funds as you dishonestly suggest.
> > >
> > > All open source software projects have within them access to the
> > > required development tools on all the common PC platforms, and so
> > > pre-compiled binaries are quick cheap and easy to provide if only
> > > the
> > > programmers could be bothered to do so.
> >
> > How do they? Most open source software projects are one or two people,
In which case, it's not what I'd call an open source software project.
The open source software I use isn't made by `one or two people'.
Firefox, LaTeX, and so on - all huge projects.
But Woody, you're just taking your usual contrarian attitude for the
sake of whipping up argument - as anonymous posters like yourself enjoy
doing. You have no basis for your claims.
> > and they certainly can't afford all the platforms. And why should they
> > pay money to provide you with something for free?
>
> Is Rowland perhaps suggesting that the developers precompile for
> platforms they don't have access to?
Not at all.
> I'm sure that's possible in a number of cases, though it's exceptionally
> foolhardy.
It's commonly done - very common, and there's no reason at all for you
to insult those who do so.
Rowland McDonnell
> Rowland McDonnell�:
>
> > R <me...@privacy.net> wrote:
> >
> >> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
> >>
> >> >An open source project that does not supply precompiled binaries is for
> >> >geeks only and is therefore almost certainly a bad open source project.
> >>
> >> Not bad.
> >
> > I think so.
> >
> >> Just not what you want.
> >
> > Just not useful for anyone at all, except for the tiny minority of
> > computer users who are `in the know' about the required development
> > tools which enable them to compile and use this software.
>
> That's a bit harsh.
<puzzled> I think that's a bit wrong of you.
> My experience with MacPorts is that it hides most of
> that for you.
So how can one trust anything, or fix anything that goes wrong, or
understand what the hell it's doing to your Mac?
I daren't use stuff like that, since I want to control what's on my
computer and things like MacPorts and Fink take that control away from
me, and leave me with - well, I don't know what littering up the `Unixy'
directory trees. What would I do if something in that area broke
something else? I wouldn't be able to figure anything out at all - this
stuff is just not safe for me to use.
>You need to download Apple's Developer tools (or install it
> from your Mac OS X media) but the procedure is not opaque.
Installing that stuff is easy. Learning how to use it is not.
> I don't know
> one end of XCode from the other,
Don't talk crap - you understand a *LOT* about it, far more than I do
from looking at it. Oh yeah, you might not know how to use it fully,
but you've got a bit of a clue. I've got none at all. I've had a
developer suggest that I might re-compile some of his software with a
minor modification. It's easy to change the code as he suggested - just
find the file containing the text that needs changing. But the
developer was surprised that I had not a clue how to re-compile the
project given that I had the full set of project files and the Apple
devtools installed.
Well, how could I? You, on the other hand, probably could have figured
it out.
> but I managed to install it (run the
> installer like every other .app) and get MacPorts running with little
> practical knowledge of the Developer tools. I haven't had to run
> makefiles, or ./configure or whatever else it is that MacPorts does (it
> all flashes by too quickly for me to see, although I could probably look
> in the logs if I could be arsed).
I'm forced to admit that things like MacPorts make stuff that's not been
compiled for Macs possible for the brave/foolhardy/ignorant to use. But
I don't trust it.
> Things were made more simple again when I got PortAuthority (see
> <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
> and makes it more accessible.
I've looked at it. Don't feel able to trust it.
> It gave me working copies of nmap and wireshark long before decent OS X
> binaries were available; and there are plenty of other useful goodies in
> the Audio section.
Uhuh. I'm aware that there's stuff available that way that's not
available other ways. But I don't see how I can trust it.
> > The aim is to deny most of us that ability, so that we can be exploited
> > by those who do.
>
> Sure - it's like maintaining your car. You can do it (and become less
> exploited by the car dealerships) if you look into it.
No, it's like maintaining your motor vehicle: if you don't do it
yourself, you're a suicidal maniac. The professionals cannot be trusted
not to kill you. Likewise, with software as with motor vehicles, you
cannot trust the `professionals' to do a competent job that won't wreak
havoc.
You can't trust the professionals and you're an idiot if you do - that's
my line. Professionals do it for the money. Those professionals who
maintain motor vehicles laugh uproariously when they discover that their
incompetence has caused another crash on the road - and they say, when
you complain `Prove it!' and laugh at your impotent rage some more.
I have *scores* of first-hand accounts of that happening.
Don't trust a professional motor vehicle mechanic - they're responsible
for much death.
> > Since the aim of providing inaccessible development tools is to deny
> > access like that, I'll stick with the idea that it's bad any time a
> > software project fails to provide precompiled binaries, because it's
> > just a way to deny access to software. And I don't like that.
>
> You could also look at it as providing access to software that wouldn't
> otherwise exist for a particular platform. Developers may not have time to
> build binaries for platforms x, y, and z,
<puzzled> But that's machine time, that is. What's the problem in
telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
time, but so what? You get four binaries in one.
Okay, that's an odd example (but normal in the Mac world). But you see,
I'm not suggesting that developers should build binaries for everything,
just that one expects to see binaries for Windoze and Macs at least,
with whatever the maximally convenient packaging for Linux-and-friends
OS users happens to be: I assume that Linux+friends have MacPorts-style
stuff to make it very very easy to get from source code to `application
in use on my computer'.
> but providing the source code
> allows binaries to be generated for platforms x, y, z, and a, b, c, and d
> as well.
Yeah, well, I'm not talking about that, am I?
> Mind you, no-one is forcing you to use it, but you're just cutting off a
> potentially very useful resource.
I'd say I'm cutting off a source of endless trouble.
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> > R <me...@privacy.net> wrote:
> > >http://sourceforge.net/projects/lame/files/lame/3.98.2/lame-398-2.tar.g
> > z/download
> >
> > Righto. Ta. Compile-it-yourself command line stuff, yes?
>
> Yes. It's not difficult and doesn't take long
My experience teaches me that it's enormously hard and takes an
impossible amount of effort to learn how to do what's needed.
>(I timed it at 32 seconds
> to extract the archive, configure, make (compile, etc.) and install).
But you have failed to factor in the decades of learning experience
which taught you what you need to know to do things so quickly in the
here&now.
> The commands used:
>
> tar xf lame-398-2.tar.gz
> cd lame-398-2
> ./configure --prefix=/usr/local
> make -j 8 install
>
> Voil�! lame ready to use.
That sort of thing is easy when you know what you do. When you don't
know what to do - as in the case of me - well, it'd take me *at least*
several hours just to repeat the above.
How come?
I know what the cd command does. I don't know what the rest of them do,
so I'd have to find out. And it's very hard to do so - several hours
minimum, more like a week or more.
There's no way I'd've been able to work out what to type on my own - and
if the instructions told me, well, it'd take me a long time to track
down the instructions and confirm that they were the applicable
instructions (I've noticed that uncompiled software usually has more
than one set of mutually contradictory installation instructions, which
the user is meant to choose between on the basis of expert knowledge
which I don't have). The idea that someone like me could compile and
use such software is not sensible.
Rowland McDonnell
That's what it looks like to me. Yes, I have tried using Audacity and I
have spent time trying to learn how to use it which means fiddling
around the Audacity site getting the hang of it.
They're like so many open-source software people - not thinking about
anything except their own personal outlook, excusing their failure to
consider anyone's use except their own with the mantra `This is how OSS
projects work, you can't expect anything else.'
I bloody well can do - I'm used to OSS like TeX, for which the author
wrote a complete manual and *FULLY* documented source code that can be
typeset into a book which really does explain everything in *FULL*
detail. My emphasis is not gratuitous.
> I agree that the interface and documentation are something else again
> :-(
Right - so the UI is awful, and the documentation likewise. And it's a
beta. So it's unfinished software which one cannot learn how to use
effectively.
> But the current "beta" (Audacity � 1.3.10-alpha-Sep 14 2009 (Unicode))
> is stable - even under Snow Leopard - and I have now used it with a USB
> deck to transcribe well over a hundred 78s, EPs and LPs...
Can you explain what role you used Audacity for in that process? Surely
all that's needed is to squirt the RIAA-equalised output from a suitable
pre-amp into an A-D converter feeding data into yer Mac somehow?
Rowland.
Rowland McDonnell
Audacity is very awkward to use mostly due to a dreadful UI that's been
cobbled together by clowns who have not a clue about usability or (as
far as I can tell) what people might want to use the software to do.
Yes, I've used Audacity. I've never hated GUIs as much - the UI gets in
the way and made everything *I* wanted to do either very hard or
impossible.
It's not really sensible to think of using Audacity if you want to do
batch conversions of files - it'd be horribly awkward for that job,
surely?
Actually, I'm not sure that Audacity is suitable for anything or anyone
except the very desperate, given its poor state of development
particularly its rotten UI.
Meanwhile, I'm working my way through this lot, trying to find out if
it's possible to get a recent version of LAME to use on my Mac:
<http://www.versiontracker.com/php/qs.php?mode=basic&action=search&str=l
ame&srchArea=macosx&submit=Go>
I was wondering if anyone could give me a bit of a hint. As far as I
can tell, the latest version of LAME is 3.98.2
<http://lame.sourceforge.net/>.
But I can't see any pre-compiled binaries for MacOS X which use that
version - the latest pre-compiled version seems to be 3.97.
E.g:
<http://www.thalictrum.com/index.php?pageid=2>
Is there a way of using any of this GUI stuff with the latest LAME, and
is there any significant downside to using v3.97 (which seems to be what
I'm going to get, like it or not)?
Cheers to anyone who can help out with that lot,
Tim Streater
It's not something I'd like to try either. Hence my use of PHP rather
than C. Of course one still has to learn PHP, but at least can avoid
make, which is revolting along with most unix utilities.
--
Tim
"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"
Bill of Rights 1689
zoara
You're humpty-dumptying again. Why should the number of people involved
determine whether it is a project or not?
> But Woody, you're just taking your usual contrarian attitude for the
> sake of whipping up argument - as anonymous posters like yourself
> enjoy
> doing. You have no basis for your claims.
Woody's not anonymous.
> > > and they certainly can't afford all the platforms. And why should
> > > they
> > > pay money to provide you with something for free?
> >
> > Is Rowland perhaps suggesting that the developers precompile for
> > platforms they don't have access to?
>
> Not at all.
Then what are you suggesting? That they buy all the platforms out there,
just so that they can precompile for them?
> > I'm sure that's possible in a number of cases, though it's
> > exceptionally
> > foolhardy.
>
> It's commonly done - very common, and there's no reason at all for you
> to insult those who do so.
Are you saying it isn't foolhardy? Pray tell, how would you propose
testing the software that is compiled to a platform that one has no
access to?
Jim
> > > How do they? Most open source software projects are one or two people,
>
> In which case, it's not what I'd call an open source software project.
> The open source software I use isn't made by `one or two people'.
> Firefox, LaTeX, and so on - all huge projects.
'Open source' has nothing to do with the number of people working on the
project.
Jim
--
"Microsoft admitted its Vista operating system was a 'less good
product' in what IT experts have described as the most ambitious
understatement since the captain of the Titanic reported some
slightly damp tablecloths." http://www.thedailymash.co.uk/
Jim
> But they don't want to do it because it would let people who are not of
> the aristocracy use their software - the *reason* for refusing to
> provide precompiled binaries is to ensure that only software developers
> (a tiny minority) can use the software.
>
> They want to deny the use of their software to most people - don't ask
> me why, but it's what they're up to.
This is so wrong it's hard to know where to begin.
Look, we get that you personally don't like compiling stuff from source
because you feel that you, personally, can't. Fine. But to claim it's
all part of some shadowy technological intelligencia is just silly.
Jim
--
http://www.ursaMinorBeta.co.uk http://twitter.com/GreyAreaUK
Please help save Bletchley Park - sign the petition for
Government funding at: (open to UK residents and ex.pats)
http://petitions.number10.gov.uk/BletchleyPark/ Thank you.
Jim
> I want to use the LAME code for encoding mp3s.
>
> I've written that - I'm sure it's what I want.
>
> If you think otherwise, then you are wrong.
Let's see now...typing "OSX LAME binary" into Google gave me this
result: <http://www.macupdate.com/info.php/id/18882>
If that doesn't work then you're probably going to have to either
compile from source, find someone who feels kindly enough to you to
compile from source for you and give you the binary, or find another
product.
Peter Ceresole
> Let's see now...typing "OSX LAME binary" into Google gave me this
> result: <http://www.macupdate.com/info.php/id/18882>
Looking at that, one of the comments is that 'it beats the pants off the
iTunes mp3 encoder' but doesn't say how or why.
Out of interest, why not just use iTunes? Why complicate life? Unless
it's just for fun, which is a good enough reason if that's what turns
you on.
--
Peter
Woody
> John Hill <ne...@erewhon.invalid> wrote:
> > I agree that the interface and documentation are something else again
> > :-(
>
> Right - so the UI is awful, and the documentation likewise. And it's a
> beta. So it's unfinished software which one cannot learn how to use
> effectively.
Many people can and have learned how to use it effectively. So its more
that you can't use it rather than one can't use it.
However, that is irrelevant in this case, what is relevant is that it
can install LAME which is what you were asking for
--
Woody
Woody
Woody
> zoara <me...@privacy.net> wrote:
>
> > Woody <use...@alienrat.co.uk> wrote:
> > > Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> > >
> > > > chris <ithi...@gmail.com> wrote:
> >
> > > > > This is not a given as
> > > > > most OSS projects don't have the funds to supply the platforms for
> > > > > the
> > > > > compilation.
> > > >
> > > > There's no need to provide special funds as you dishonestly suggest.
> > > >
> > > > All open source software projects have within them access to the
> > > > required development tools on all the common PC platforms, and so
> > > > pre-compiled binaries are quick cheap and easy to provide if only
> > > > the
> > > > programmers could be bothered to do so.
> > >
> > > How do they? Most open source software projects are one or two people,
>
> In which case, it's not what I'd call an open source software project.
> The open source software I use isn't made by `one or two people'.
> Firefox, LaTeX, and so on - all huge projects.
So what - they are large open source software projects, there are small
ones too.
> But Woody, you're just taking your usual contrarian attitude for the
> sake of whipping up argument
No I am not, I am replying to you as you are talking out of your arse
again.
>- as anonymous posters like yourself enjoy
> doing.
Anonymous? I am less anonymous than you, other people here have met me,
I use my own name and I have a real address on my from line, unlike you.
> You have no basis for your claims.
Have a look at the statistics on sourceforge. Where are your statistics
from?
--
Woody
Woody
But why? what is the difference from just copying that above to
installing a precompiled binary?
But if you really want to know:
> tar xf lame-398-2.tar.gz
runs tar to extract the files in that archive (eXtract File) to the
structure built into it
> cd lame-398-2
change into the new structure
> ./configure --prefix=/usr/local
runs the ./configure script, which is part of the autoconf utilites,
which works out (from your environmental variables) what platform you
are on, and writes a data file for the make process that matches your
platform (and ultimately produces a 'make' file). I this case there is a
parameter added to tell it to install itself in /usr/local - I never
bother with that but if you want control over where it goes it is handy
> make -j 8 install
run make, and use the 'install' flag, which compiles, links and then
installs it in /usr/local/bin
--
Woody
Woody
I think that goes back to the mechanic argument. If you want to build
something yourself, build it from source, as previously mentioned it
only takes 5 lines, assuming you have installed the developer tools.
If you don't want to do that, use iTunes. You are not being denied
anything, you just have more options if you want to do it yourself, like
most other things in life.
--
Woody
John Hill
> John Hill <ne...@erewhon.invalid> wrote:
>
> > Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> >
> > > John Hill <ne...@erewhon.invalid> wrote:
> > >
Snip...
Firstly, as Woody pointed out, you can use LAME with it, and that was
what you were asking about.
Secondly, to reply to your last point, I bought a USB deck specifically
to transcribe the old discs, and Audacity came with it. Evidently the
deck manufacturer thought it was the best available application to
accompany it.
And the transcription process, to be worth while, is more than just
squirting the data into the Mac. For 78s (10 and 12 inch) you have to
get the raw digital data into the Mac, and Audacity does that well. But
it is actually recorded at 45 rpm and has to be converted to 78 rpm (in
once case of an old Columbia record, 80 rpm). (EPs and LPs are obviously
recorded at their correct speed.)
After that, for all transcriptions, the file has to be checked for noise
and as much as possible removed. (This takes time and care - one 1915
recording of Caruso was very noisy, but if you try to remove too much
the quality of what is left is ruined.) Clicks and pops have to be
removed. In the case of one 1930s 78 disc, which had a crack part-way
across the disc, the damage had to be repaired. (This takes time and
patience, and examination of the transcription in minute detail in the
affected areas.)
A few records had faults that needed attention - needle jump which had
to be corrected, for example.
Next you have to normalise the recording in the case of mono records,
and amplify it to some sort of standard level in the case of stereo
(some recordings are really faint, others boom at you).
One or two 78s (Eric Coats's The Three Bears for example) were on two
sides of a 78 and had to be joined up.
Finally you have to divide LPs (and some 78s - Trial by Jury, for
example) into tracks and name the tracks. You then use Audacity's Export
Multiple to get someting suitable for iTunes and an iPod. This, at long
last, is where LAME is used.
Audacity has built-in tools for all of these tasks. It probably isn't
the only application that does, but I learned to use enough of it
(probably less than 10% of its capability) to do what I wanted. It is
clearly designed for the serious music user, who will be prepared to
learn how to use it (and to report problems, which I had to do once -
the problem was fixed).
All that remains to do in iTunes is to insert the composer and some
other minor details - whether part of a compilation, disc number and
group, for example - and see to the artwork (though for the 78s and the
majority of EPs, there isn't any, unless you can find something
approprate on the Internet).
Sorry to bang on, but you DID ask!
Woody
> It's not something I'd like to try either. Hence my use of PHP rather
> than C. Of course one still has to learn PHP, but at least can avoid
> make, which is revolting along with most unix utilities.
Make is pretty horible, yes, although I don't know if I would have the
patience to batch encode mp3s using a PHP mp3 encoder!
--
Woody
Pd
> > But they don't want to do it because it would let people who are not of
> > the aristocracy use their software
> Look, we get that you personally don't like compiling stuff from source
> because you feel that you, personally, can't. Fine. But to claim it's
> all part of some shadowy technological intelligencia is just silly.
Ah, Jim, we need to have a word. I know you haven't been officially
invited to join the cabal yet, but I think it's high time. Obviously I
can't say too much in public, so for the moment just make sure you
respond quickly to any communications addressed to "The Marquis of
Magrathea", hmm?
--
Pd
Jim
This won't have anything to do with Wellington boot, custard and loofahs
will it?
My Oasis of Calm has dried up. However, my Garden of Angry is
flourishing quite nicely.
Mark Bestley
OK you asked for precompiled stuff first so it was suggested that
although Macports is from source it also works like a black box so that
you do not need the details so that it is very similar to precompiled
software (Fink does provide precompiled software)
Then you complain that it hides everything - well it doesn't it shows in
script exactly what it does. Precompiled software tells you nothing of
what it does - how do you know it is not a trojan, do you know if it
copies data to a third party? Thus I think you are being inconsistent
here. If you want to know what a program does exactly and be able to fix
it then you have to compile form source - see the 'manifestos' for open
source this being able to fix what happens is given as a main reason for
open source and why nothing else can be trusted.
And you trust random executables from the web?
> > Things were made more simple again when I got PortAuthority (see
> > <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
> > and makes it more accessible.
>
> I've looked at it. Don't feel able to trust it.
>
> > It gave me working copies of nmap and wireshark long before decent OS X
> > binaries were available; and there are plenty of other useful goodies in
> > the Audio section.
>
> Uhuh. I'm aware that there's stuff available that way that's not
> available other ways. But I don't see how I can trust it.
>
> > > The aim is to deny most of us that ability, so that we can be exploited
> > > by those who do.
> >
> > Sure - it's like maintaining your car. You can do it (and become less
> > exploited by the car dealerships) if you look into it.
>
> No, it's like maintaining your motor vehicle: if you don't do it
> yourself, you're a suicidal maniac. The professionals cannot be trusted
> not to kill you. Likewise, with software as with motor vehicles, you
> cannot trust the `professionals' to do a competent job that won't wreak
> havoc.
>
But as you can;t compile software you are trusting professionals here.
> You can't trust the professionals and you're an idiot if you do - that's
> my line. Professionals do it for the money. Those professionals who
> maintain motor vehicles laugh uproariously when they discover that their
> incompetence has caused another crash on the road - and they say, when
> you complain `Prove it!' and laugh at your impotent rage some more.
>
> I have *scores* of first-hand accounts of that happening.
>
> Don't trust a professional motor vehicle mechanic - they're responsible
> for much death.
>
> > > Since the aim of providing inaccessible development tools is to deny
> > > access like that, I'll stick with the idea that it's bad any time a
> > > software project fails to provide precompiled binaries, because it's
> > > just a way to deny access to software. And I don't like that.
> >
No it is beacuse many open source developers want to gove ypu control of
the software and fix any issues and do not qant to hide things away.
Like you they distrust 'professionals' so they give you the information
to do it yourself.
> > You could also look at it as providing access to software that wouldn't
> > otherwise exist for a particular platform. Developers may not have time to
> > build binaries for platforms x, y, and z,
>
> <puzzled> But that's machine time, that is. What's the problem in
> telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> time, but so what? You get four binaries in one.
>
> Okay, that's an odd example (but normal in the Mac world). But you see,
> I'm not suggesting that developers should build binaries for everything,
> just that one expects to see binaries for Windoze and Macs at least,
> with whatever the maximally convenient packaging for Linux-and-friends
> OS users happens to be: I assume that Linux+friends have MacPorts-style
> stuff to make it very very easy to get from source code to `application
> in use on my computer'.
>
> I'd say I'm cutting off a source of endless trouble.
>
But as you say 'I daren't use stuff like that, since I want to control
what's on my computer ' and you can ONLY do that if you do your own
compiles.
--
Mark
Tim Streater
>> But they don't want to do it because it would let people who are not of
>> the aristocracy use their software
> Look, we get that you personally don't like compiling stuff from source
> because you feel that you, personally, can't. Fine. But to claim it's
> all part of some shadowy technological intelligentsia is just silly.
In the strict sense, yes of course. But I, for example, would avoid
doing development in C under unix as much as possible, because of stuff
like 'make'. The docs (such as they are) are generally piss-poor, and
too often refer to another version than the one actually installed.
Further, the general tenor of unix (and perl) is that docs are written
by "gurus" for "newbies", who had better remember their place in the
scheme of things. This is evidenced by the often rude reception to
"newbies" who blunder uninvited into some of the technical NGs. I recall
just this when asking a question in the perl ng about parameter passing.
But the hothots there were all too busy in discussing how to reduce
their programs to a .
alt.html has Mr Yucky, c.s.javascript has Mr Pointyhead. Sure, these
folks know a lot and indeed help a lot, but a lot of genuflection is
required before they loftily condescend to help.
By contrast the PHP docs are written by intelligent adults for
intelligent adults, another reason that I prefer to use it.
Steve Firth
> >
> > i.e., we don't give a shit about whether anyone can actually use this
> > software, we're just wankers having a good old wank.
>
> Fair enough.
Not really it's old Rowland McBollocks talking cack, again.
Pd
> On 2009-11-26, Pd <peter...@gmail.invalid> wrote:
> > Jim <j...@magrathea.plus.com> wrote:
> >
> >> > But they don't want to do it because it would let people who are not of
> >> > the aristocracy use their software
> >
> >> Look, we get that you personally don't like compiling stuff from source
> >> because you feel that you, personally, can't. Fine. But to claim it's
> >> all part of some shadowy technological intelligencia is just silly.
> >
> > Ah, Jim, we need to have a word. I know you haven't been officially
> > invited to join the cabal yet, but I think it's high time. Obviously I
> > can't say too much in public, so for the moment just make sure you
> > respond quickly to any communications addressed to "The Marquis of
> > Magrathea", hmm?
>
> This won't have anything to do with Wellington boot, custard and loofahs
> will it?
Er, no.
That's to do with that lot where you are known as "Sir Squelchy Jimpot".
--
Pd
Jim
Thank goodness for that. I hate custard.
Woody
> Jim <j...@magrathea.plus.com> wrote:
>
> >> But they don't want to do it because it would let people who are
> > > not of
> >> the aristocracy use their software
>
> > Look, we get that you personally don't like compiling stuff from
> > source
> > because you feel that you, personally, can't. Fine. But to claim
> > it's
> > all part of some shadowy technological intelligentsia is just silly.
>
> In the strict sense, yes of course. But I, for example, would avoid
> doing development in C under unix as much as possible, because of
> stuff
> like 'make'. The docs (such as they are) are generally piss-poor, and
> too often refer to another version than the one actually installed.
If you are developing for yourself or not giving the source away, you
don't have to touch make, any more than you do in the mac
> Further, the general tenor of unix (and perl) is that docs are written
>
> by "gurus" for "newbies", who had better remember their place in the
> scheme of things. This is evidenced by the often rude reception to
> "newbies" who blunder uninvited into some of the technical NGs. I
> recall
> just this when asking a question in the perl ng about parameter
> passing.
> But the hothots there were all too busy in discussing how to reduce
> their programs to a .
>
> alt.html has Mr Yucky, c.s.javascript has Mr Pointyhead. Sure, these
> folks know a lot and indeed help a lot, but a lot of genuflection is
> required before they loftily condescend to help.
Is this not more a reflection of the alt.* heirachy of usenet? There are
lots of resources on the web, forums and other sites that are freindly
and helpful
> By contrast the PHP docs are written by intelligent adults for
> intelligent adults, another reason that I prefer to use it.
So is alt.php a freindly place?
--
Woody
Jim
<snip>
Right, having a spare minute I thought I'd take a look into this for shits
and giggles. You want a pre-compiled version of lame for OS X? Here's one
way of doing it.
First of all download Amadeus Pro from
<http://www.hairersoft.com/AmadeusPro/AmadeusProDownload.html>
Install it.
Navigate to the application in the Finder. Right click and choose 'Show
package contents'
Navigate to Contents/PlugIns/Mp3 Support.bundle/Contents/Resources/lame
(I'm guessing you might have to right-click and do 'Show package contents'
on the 'Mp3 Support.bundle' bit)
That's the command-line tool, so far as I can tell. Move (or copy) it
somewhere where command line tools are happy.
Delete Amadeus Pro (unless you intend to buy it).
Be happy.
Now, I can't actually test any of this because (a) my copy of Pro is old-ish
as I haven't fired it up in a while, and (b) I'm doing all of this through
an ssh session. But I'd be surprised if the above isn't at least close.
Jaimie Vandenbergh
wrote:
>Secondly, to reply to your last point, I bought a USB deck specifically
>to transcribe the old discs, and Audacity came with it. Evidently the
>deck manufacturer thought it was the best available application to
>accompany it.
(plus the licensing is cheap... I'm sure that's a factor)
>And the transcription process, to be worth while, is more than just
>squirting the data into the Mac. [huge snip]
I don't expect you'll get any gratitude from Rowland, so I wanted to
say thank you very much for posting that - recording my LPs etc is one
of those Things To Do When I'm Off Work With A Broken Leg type
projects, and I had no idea Audacity had so much of this stuff built
in.
Cheers - Jaimie
--
Okay, it works now. Or at least it malfunctions in all the expected ways.
-- Mark Edwards, asr
Tim Streater
> Tim Streater<timst...@waitrose.com> wrote:
>> By contrast the PHP docs are written by intelligent adults for
>> intelligent adults, another reason that I prefer to use it.
>
> So is alt.php a friendly place?
I was more thinking of the PHP website. F'rinstance:
James Dore
<real-addr...@flur.bltigibbet.invalid> wrote:
> James Dore <james...@new.ox.ac.uk> wrote:
>
>> Rowland McDonnellￜ:
>>
>> > R <me...@privacy.net> wrote:
>> >
>> >> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell)
>> wrote:
>> >>
>> >> >An open source project that does not supply precompiled binaries is
>> for
>> >> >geeks only and is therefore almost certainly a bad open source
>> project.
>> >>
>> >> Not bad.
>> >
>> > I think so.
>> >
>> >> Just not what you want.
>> >
>> > Just not useful for anyone at all, except for the tiny minority of
>> > computer users who are `in the know' about the required development
>> > tools which enable them to compile and use this software.
>>
>> That's a bit harsh.
>
> <puzzled> I think that's a bit wrong of you.
>
>> My experience with MacPorts is that it hides most of
>> that for you.
>
> So how can one trust anything, or fix anything that goes wrong, or
> understand what the hell it's doing to your Mac?
Logs. In the same way that Installer leaves logfiles for you to read via
Console, you can read the MacPorts logs. Installation occurs witin
specific portions of the filesystem, *away* from important things eg.
/Library or /System or /Users. If there are issues with it, you can copy
and paste a script off the MacPorts site into terminal to nuke the whole
lot. Normal service is then resumed.
> I daren't use stuff like that, since I want to control what's on my
> computer and things like MacPorts and Fink take that control away from
> me, and leave me with - well, I don't know what littering up the `Unixy'
> directory trees. What would I do if something in that area broke
> something else? I wouldn't be able to figure anything out at all - this
> stuff is just not safe for me to use.
>
>> You need to download Apple's Developer tools (or install it
>> from your Mac OS X media) but the procedure is not opaque.
>
> Installing that stuff is easy. Learning how to use it is not.
>
>> I don't know
>> one end of XCode from the other,
>
> Don't talk crap - you understand a *LOT* about it, far more than I do
> from looking at it. Oh yeah, you might not know how to use it fully,
> but you've got a bit of a clue.
Seriously?!
Nope. I am not a programmer. I have not been taught programming, and
although I would like to learn some, I have much else to do, and frankly,
it bores me to tears. The only thing I dislike more than programming is
writing web pages. I can at least understand HTML, a very small bit of PHP
and some SQL, but I have never opened the Xcode development tools even to
look at.
> I've got none at all. I've had a
> developer suggest that I might re-compile some of his software with a
> minor modification. It's easy to change the code as he suggested - just
> find the file containing the text that needs changing. But the
> developer was surprised that I had not a clue how to re-compile the
> project given that I had the full set of project files and the Apple
> devtools installed.
>
> Well, how could I? You, on the other hand, probably could have figured
> it out.
Yes, but I'm not special in that regard.
>> but I managed to install it (run the
>> installer like every other .app) and get MacPorts running with little
>> practical knowledge of the Developer tools. I haven't had to run
>> makefiles, or ./configure or whatever else it is that MacPorts does (it
>> all flashes by too quickly for me to see, although I could probably look
>> in the logs if I could be arsed).
>
> I'm forced to admit that things like MacPorts make stuff that's not been
> compiled for Macs possible for the brave/foolhardy/ignorant to use. But
> I don't trust it.
>
>> Things were made more simple again when I got PortAuthority (see
>> <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
>> and makes it more accessible.
>
> I've looked at it. Don't feel able to trust it.
>
>> It gave me working copies of nmap and wireshark long before decent OS X
>> binaries were available; and there are plenty of other useful goodies in
>> the Audio section.
>
> Uhuh. I'm aware that there's stuff available that way that's not
> available other ways. But I don't see how I can trust it.
Basically, it's been looked at by many other, independent, minds, far more
clueful than mine. The nature of these things is that if something is
wrong with the source code, people will spot it, and scream at the
developer. It's informal peer-review, and the process is not limited to
the organisation that has produced the code. Generally, this means that
there is less chance of flaws remaining hidden. True, flaws in source code
or incorrect function can be exploited by the nefarious more quickly, but
they have to get their exploits in quick since the developers of the buggy
code soon have world+dog screaming at them for an update.
>> > The aim is to deny most of us that ability, so that we can be
>> exploited
>> > by those who do.
>>
>> Sure - it's like maintaining your car. You can do it (and become less
>> exploited by the car dealerships) if you look into it.
>
> No, it's like maintaining your motor vehicle: if you don't do it
> yourself, you're a suicidal maniac. The professionals cannot be trusted
> not to kill you. Likewise, with software as with motor vehicles, you
> cannot trust the `professionals' to do a competent job that won't wreak
> havoc.
There is some truth in that, but I'd rather trust a specialist to service
the high-pressure side of my vehicles' diesel engines than me; likewise
the Aircon systems; and I'd rather have a tyre fitted by a pro than strain
over it myself for a week. Basic maintenance is doable, but there are jobs
I need to outsource.
> You can't trust the professionals and you're an idiot if you do - that's
> my line. Professionals do it for the money. Those professionals who
> maintain motor vehicles laugh uproariously when they discover that their
> incompetence has caused another crash on the road - and they say, when
> you complain `Prove it!' and laugh at your impotent rage some more.
>
> I have *scores* of first-hand accounts of that happening.
>
> Don't trust a professional motor vehicle mechanic - they're responsible
> for much death.
Maybe so, and being mildly suspicious is always a good idea, but my
experience differs from yours; I've not had bad experiences with motor
services (motor /sales/ are another matter entirely :-) - only one
noteworthily good I suppose - the TR7 was collected, and they found out
why it kept misfiring. Turned out that it would destroy rotor arms
quickly, but not so you could see: The current would earth through the
supposedly non-conductive rotor arm body down the distributor. Repeatable
with new rotor arms after a few months driving. New arm on, problem gone,
but a the old one was measurably conductive. Weird.
>> > Since the aim of providing inaccessible development tools is to deny
>> > access like that, I'll stick with the idea that it's bad any time a
>> > software project fails to provide precompiled binaries, because it's
>> > just a way to deny access to software. And I don't like that.
>>
>> You could also look at it as providing access to software that wouldn't
>> otherwise exist for a particular platform. Developers may not have time
>> to
>> build binaries for platforms x, y, and z,
>
> <puzzled> But that's machine time, that is. What's the problem in
> telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> time, but so what? You get four binaries in one.
Fine if you're Mac-specific. But source should be able to be complied on
Mac PPC 32/64 bit, Intel 32/64 bit, Windows 32/64 bit, Linux flavours,
Solaris flavours, BSD Flavours, IBM AIX flavours, HP-UX flavours, BeOS,
etc ad nauseam. Much wider target market for the developers without having
to have a development environment for each (often expensive) platform to
compile the binaries on. Time could be rented for testing purposes on such
platforms of course, but often users of these kinds of applications will
donate that testing in return for credit and favours (new features, early
updates, etc). Mutual back scratching which benefits all parties.
> Okay, that's an odd example (but normal in the Mac world). But you see,
> I'm not suggesting that developers should build binaries for everything,
> just that one expects to see binaries for Windoze and Macs at least,
> with whatever the maximally convenient packaging for Linux-and-friends
> OS users happens to be: I assume that Linux+friends have MacPorts-style
> stuff to make it very very easy to get from source code to `application
> in use on my computer'.
>
>> but providing the source code
>> allows binaries to be generated for platforms x, y, z, and a, b, c, and
>> d
>> as well.
>
> Yeah, well, I'm not talking about that, am I?
Maybe not, but that's the model into which MacPorts fits; part of a
development ecosystem that serves many platforms simultaneously, and with
little cost to the developer.
>> Mind you, no-one is forcing you to use it, but you're just cutting off a
>> potentially very useful resource.
>
> I'd say I'm cutting off a source of endless trouble.
Given your experiences, perhaps so. Many others have different experiences.
Cheers,
--
James Dore
New College IT Officer
james.dore@new / it-support@new
Ben Shimmin
[...]
> alt.html has Mr Yucky, c.s.javascript has Mr Pointyhead. Sure, these
> folks know a lot and indeed help a lot, but a lot of genuflection is
> required before they loftily condescend to help.
I browse through comp.lang.javascript sometimes, and, I have to say,
the guys in there, whilst very clued up, are pretty off-putting in
terms of their attitude. They also seem to spend a ridiculous amount
of time arguing about how exactly Opera 9.x behaves with clientWidth
and clientHeight, and other such fascinating topics.
b.
--
<b...@bas.me.uk> <URL:http://bas.me.uk/>
`Property, marriage, the law; as the bed to the river, so rule
and convention to the instinct; and woe to him who tampers with
the banks while the flood is flowing.' -- Samuel Butler, _Erewhon_
Tim Streater
> Tim Streater<timst...@waitrose.com>:
>
> [...]
>
>> alt.html has Mr Yucky, c.s.javascript has Mr Pointyhead. Sure, these
>> folks know a lot and indeed help a lot, but a lot of genuflection is
>> required before they loftily condescend to help.
>
> I browse through comp.lang.javascript sometimes, and, I have to say,
> the guys in there, whilst very clued up, are pretty off-putting in
> terms of their attitude. They also seem to spend a ridiculous amount
> of time arguing about how exactly Opera 9.x behaves with clientWidth
> and clientHeight, and other such fascinating topics.
:-)
Angels and pinheads come to mind.
Woody
> On 26/11/2009 11:01, Woody wrote:
> > Tim Streater<timst...@waitrose.com> wrote:
>
> >> By contrast the PHP docs are written by intelligent adults for
> >> intelligent adults, another reason that I prefer to use it.
> >
> > So is alt.php a friendly place?
>
> I was more thinking of the PHP website. F'rinstance:
>
> http://uk3.php.net/manual/en/
Yes I am familiar with that, I just wondered if alt.php wouldn't suffer
the same problems as any other programming newsgroups that you said
about?
Ie, the problem of newbie friendliness that you attribute to C on unix
is more just a problem the alt.* newsgroups?
I do know what you mean, I have experienced it, but I suspect that the
layout and accesability of php.net is more a function of being a
commercial entities website
I also suspect that the documentation there won't be up to what Rowland
wants
--
Woody
Woody
> Tim Streater <timst...@waitrose.com>:
>
> [...]
>
> > alt.html has Mr Yucky, c.s.javascript has Mr Pointyhead. Sure, these
> >
> > folks know a lot and indeed help a lot, but a lot of genuflection is
> >
> > required before they loftily condescend to help.
>
> I browse through comp.lang.javascript sometimes, and, I have to say,
> the guys in there, whilst very clued up, are pretty off-putting in
> terms of their attitude. They also seem to spend a ridiculous amount
> of time arguing about how exactly Opera 9.x behaves with clientWidth
> and clientHeight, and other such fascinating topics.
Isn't that the sort of thing you would expect them to be arguing about
though?
--
Woody
Ben Shimmin
> Ben Shimmin <b...@llamaselector.com> wrote:
[...]
>> I browse through comp.lang.javascript sometimes, and, I have to say,
>> the guys in there, whilst very clued up, are pretty off-putting in
>> terms of their attitude. They also seem to spend a ridiculous amount
>> of time arguing about how exactly Opera 9.x behaves with clientWidth
>> and clientHeight, and other such fascinating topics.
>
> Isn't that the sort of thing you would expect them to be arguing about
> though?
Well, yes -- a major part of doing stuff with JavaScript is making it
work across different browsers. Attempting to avoid that sort of
nonsense is one reason one might use jQuery, for example, except at
least some of the people in comp.lang.javascript spend a lot of time
denigrating that too.
Tim Streater
> Tim Streater<timst...@waitrose.com> wrote:
>> On 26/11/2009 11:01, Woody wrote:
>>> Tim Streater<timst...@waitrose.com> wrote:
>>
>>>> By contrast the PHP docs are written by intelligent adults for
>>>> intelligent adults, another reason that I prefer to use it.
>>>
>>> So is alt.php a friendly place?
>>
>> I was more thinking of the PHP website. F'rinstance:
>>
>> http://uk3.php.net/manual/en/
>
> Yes I am familiar with that, I just wondered if alt.php wouldn't suffer
> the same problems as any other programming newsgroups that you said
> about?
> Ie, the problem of newbie friendliness that you attribute to C on unix
> is more just a problem the alt.* newsgroups?
> I do know what you mean, I have experienced it, but I suspect that the
> layout and accesability of php.net is more a function of being a
> commercial entities website
Well - the "unfriendly" behaviour doesn't only afflict the alt.* groups.
If php.net is more friendly because its commercial then that's all to
the good, although I don't understand what their revenue stream might be.
> I also suspect that the documentation there won't be up to what Rowland
> wants
No, it's aimed at programmers, and if Rowland isn't one then it won't
help. But becoming a programmer is not something that happens overnight
and after reading a few manuals, anyway, so I don't know what to suggest
to help him. It's 44 years since I first wrote a bit of software (on the
Elliot 803 in the Optics Dept at Imperial).
That was also my first lesson in practical programming, too. I tried to
extract square roots using Newton's method, and unwisely tested for
convergence by comparing floating point numbers for equality, or zero,
or something.
zoara
> On 2009-11-26, Pd <peter...@gmail.invalid> wrote:
> > Jim <j...@magrathea.plus.com> wrote:
> >
> >> > But they don't want to do it because it would let people who are
> > > > not of
> >> > the aristocracy use their software
> >
> >> Look, we get that you personally don't like compiling stuff from
> > > source
> >> because you feel that you, personally, can't. Fine. But to claim
> > > it's
> >> all part of some shadowy technological intelligencia is just silly.
> >
> > Ah, Jim, we need to have a word. I know you haven't been officially
> > invited to join the cabal yet, but I think it's high time. Obviously
> > I
> > can't say too much in public, so for the moment just make sure you
> > respond quickly to any communications addressed to "The Marquis of
> > Magrathea", hmm?
>
> This won't have anything to do with Wellington boot, custard and
> loofahs
> will it?
Yes, but you have to make your own custard. Those who cannot, or refuse
to follow a recipe, are not admitted into the Cabal.
-zoara-
--
email: nettid1 at fastmail dot fm
zoara
> Jim <j...@magrathea.plus.com> wrote:
>
> > Let's see now...typing "OSX LAME binary" into Google gave me this
> > result: <http://www.macupdate.com/info.php/id/18882>
>
> Looking at that, one of the comments is that 'it beats the pants off
> the
> iTunes mp3 encoder' but doesn't say how or why.
The general consensus is that it sounds better at the same bitrate. I
haven't seen any double-blind tests, so don't know whether that's
actually true.
Disk space is so cheap these days that it just seems simpler to encode
at a higher rate than mess about with using LAME.
Though I use AAC - don't even know whether LAME can do that (and I'm not
really bothered if it does).
Peter Ceresole
> Yes, but you have to make your own custard. Those who cannot, or refuse
> to follow a recipe, are not admitted into the Cabal.
Except for people like me, who set up the cabal (which doesn't exist)
and wrote the rules (which don't exist) and who can make any damn
flavour of custard that we want. And I refuse to accept your
gratuitously insulting posts on this subject.
--
Peter
David Sankey
pe...@cara.demon.co.uk (Peter Ceresole) wrote:
Mornington Crescent!
Jim
Well, you may well think that, buMY GODS! WHAT'S THAT BEHIND YOU?!
[runs away]
James Dore
> On 2009-11-26, Peter Ceresole <pe...@cara.demon.co.uk> wrote:
>> zoara <me...@privacy.net> wrote:
>>
>>> Yes, but you have to make your own custard. Those who cannot, or refuse
>>> to follow a recipe, are not admitted into the Cabal.
>>
>> Except for people like me, who set up the cabal (which doesn't exist)
>> and wrote the rules (which don't exist) and who can make any damn
>> flavour of custard that we want. And I refuse to accept your
>> gratuitously insulting posts on this subject.
>
> Well, you may well think that, buMY GODS! WHAT'S THAT BEHIND YOU?!
>
> [runs away]
Oh yeah, nice try sunshine. You won't fool me with tha
+ + + NO CARRIER + + +
Peter Ceresole
> > Well, you may well think that, buMY GODS! WHAT'S THAT BEHIND YOU?!
> >
> > [runs away]
>
> Oh yeah, nice try sunshine. You won't fool me with tha
>
>
> + + + NO CARRIER + + +
By god, that does remind me of Fido days...
--
Peter
Jaimie Vandenbergh
It's an mp3 encoder, so nope.
And however tempting, I'm not going to go back and slurp in several
hundred CDs as lossless, even though I've plenty of space to do it...
Cheers - Jaimie
--
"Those are my principles. If you don't like them, I have others."
- Groucho Marx
Jim
>> > Well, you may well think that, buMY GODS! WHAT'S THAT BEHIND YOU?!
>> >
>> > [runs away]
>>
>> Oh yeah, nice try sunshine. You won't fool me with tha
>>
>>
>> + + + NO CARRIER + + +
>
> By god, that does remind me of Fido days...
I star&&&%ted out.. &using *---.an acc^^oustic ;;;couple^@@#r.
And yes, it really was that bad. I remember smothering the thing in pillows
in order to muffle the external sound as much as possible. It looked like I
was trying to kill someone very, very small.
T i m
wrote:
>I star&&&%ted out.. &using *---.an acc^^oustic ;;;couple^@@#r.
>
>And yes, it really was that bad. I remember smothering the thing in pillows
>in order to muffle the external sound as much as possible. It looked like I
>was trying to kill someone very, very small.
>
I only had any of that with the Trim Phones (706 / 746's were fine).
;-)
About the same time I was repairing 300 baud modems for BT. As big and
heavy as a desktop PC, complete with drop down front and slide out
rack modules for the Modulator, De-Modulator, PSU, Filter and Control
unit etc etc.
The filter was in a tin box and you had to first desolder the lid to
be able to re-tune the filter, re-soldering the lid when you had
finished.
What was good about them is you were able to break down the functions
of the MoDem and see how it all worked.
I've still got a battery powered acoustic coupler somewhere and have
actually used that and a Toshiba laptop (luggable, with real 16bit ISA
slots) in a phone box.
Them were the days. ;-)
Cheers, T i m
Jim
> On Thu, 26 Nov 2009 15:52:48 +0000, Jim <j...@magrathea.plus.com>
> wrote:
>
>>I star&&&%ted out.. &using *---.an acc^^oustic ;;;couple^@@#r.
>>
>>And yes, it really was that bad. I remember smothering the thing in pillows
>>in order to muffle the external sound as much as possible. It looked like I
>>was trying to kill someone very, very small.
>>
> I only had any of that with the Trim Phones (706 / 746's were fine).
> ;-)
This was just a really crappy accoustic couple. Solid moulded plastic, no
cups. I'm not at all surprised it was as bad as it was.
Pd
> Navigate to Contents/PlugIns/Mp3 Support.bundle/Contents/Resources/lame
>
> (I'm guessing you might have to right-click and do 'Show package contents'
> on the 'Mp3 Support.bundle' bit)
>
> That's the command-line tool, so far as I can tell. Move (or copy) it
> somewhere where command line tools are happy.
Mine's the latest version of Amadeus Pro v1.45, and the resource for the
command line tool says it's LAME 32bits version 3.98.2 which is the
latest build.
--
Pd
Jim
He has a solution then. Yay usenet.
Phil Taylor
<1j9rkzi.1dfqtw1lrc7uoN%real-addr...@flur.bltigibbet.invalid>,
Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> Phil Taylor <not...@all.invalid> wrote:
>
> > John Hill <ne...@erewhon.invalid> wrote:
> >
> > > Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> > >
> > > > So I am.
> > > >
> > > > I've had a look out there in Webland, trying to figure out what to get
> > > > to encode mp3s using LAME.
> > > >
> > > > And I'm all confused at the range of stuff out there. How is one to
> > > > choose?
> > > >
> > > > What do people here like by way of LAME encoders on MacOS X?
> > > >
> > > > (Core2Duo iMac, 10.6.2)
> > > >
> > > > Rowland.
> > >
> > > Audacity? or is that overkill? <http://audacity.sourceforge.net/>
> >
> > That would be my suggestion too. Older versions of Audacity used to
> > require the separate installation of LAME. but now I think the code is
> > built in. It will open most audio files (aiff, wave, au, ogg, mp3
> > etc.) and export them. Does a good job on mp3s too.
>
> Audacity is very awkward to use mostly due to a dreadful UI that's been
> cobbled together by clowns who have not a clue about usability or (as
> far as I can tell) what people might want to use the software to do.
>
> Yes, I've used Audacity. I've never hated GUIs as much - the UI gets in
> the way and made everything *I* wanted to do either very hard or
> impossible.
Well, there's no accounting for tastes, especially where GUIs are
concerned.
It's a Carbon app, and therefore a bit old-fashioned in appearance. I
like that, though. I like programs that work with visible files,
through the Finder, and where all the commands are present on menus and
have sensible names. I tend to avoid the more modern stuff where
everything is hidden away from you and you have to use the
documentation a lot to figure out how to use it.
Like John, I've used Audacity for transcribing and massaging old audio
material, and I don't think I have ever even looked at the
documentation. The UI is sufficiently similar to other audio programs
I've used that it was always very easy to figure out.
I suppose that if you've never used any audio programs before it could
seem a bit intimidating.
>
> It's not really sensible to think of using Audacity if you want to do
> batch conversions of files - it'd be horribly awkward for that job,
> surely?
I don't think it has any batch processing built in, so unless it is
AppleScriptable then you couldn't do that. no.
Phil Taylor
T i m
wrote:
>On 2009-11-26, T i m <ne...@spaced.me.uk> wrote:
>> On Thu, 26 Nov 2009 15:52:48 +0000, Jim <j...@magrathea.plus.com>
>> wrote:
>>
>>>I star&&&%ted out.. &using *---.an acc^^oustic ;;;couple^@@#r.
>>>
>>>And yes, it really was that bad. I remember smothering the thing in pillows
>>>in order to muffle the external sound as much as possible. It looked like I
>>>was trying to kill someone very, very small.
>>>
>> I only had any of that with the Trim Phones (706 / 746's were fine).
>> ;-)
>
>This was just a really crappy accoustic couple. Solid moulded plastic, no
>cups. I'm not at all surprised it was as bad as it was.
Ah, nor me then.
The one I first used had wobbly rubber cups in an otherwise rigid ABS
case and the second (battery) one had a Bendy-bus flexible middle to
it (and rubber cups).
Slow but worked. ;-)
T i m
Jaimie Vandenbergh
>Rowland McDonnell wrote:
>> So I am.
>>
>> I've had a look out there in Webland, trying to figure out what to get
>> to encode mp3s using LAME.
>>
>> And I'm all confused at the range of stuff out there. How is one to
>> choose?
>
>There's only one LAME:
>http://lame.sourceforge.net/download.php
>
>And like all good open source projects you have to download and compile
>it yourself. On the Mac you're probably better off installing it via
>Fink or MacPorts.
>
>> What do people here like by way of LAME encoders on MacOS X?
>
>Lame is a commandline only tool, but there may be GUI tools for the Mac
>which use lame as the backend encoder.
Max uses LAME as the MP3 encoder. It's simple enough to work.
http://sbooth.org/Max/
Go to its Prefs/Formats, add mp3 to the top box if it's not there.
Tick it as the destination. Press "encoder settings" and set the
options.
File/Convert Files to set up your queue. Set the metadata here as
well, if needed.
Cheers - Jaimie
--
"If this crazy idealistic 'dont-eat-people' idea of yours was to catch
on, I just don't know where we would all be. Fortunately, I suppose it
catching on isn't really very likely -- why, you might just as well go
around saying 'Don't fight people'..." -- Flanders & Swann
Bruce Horrocks
> On 2009-11-26, Pd <peter...@gmail.invalid> wrote:
>>>> invited to join the cabal yet, but I think it's high time. Obviously I
>>>> can't say too much in public, so for the moment just make sure you
>>>> respond quickly to any communications addressed to "The Marquis of
>>>> Magrathea", hmm?
>>> This won't have anything to do with Wellington boot, custard and loofahs
>>> will it?
>> That's to do with that lot where you are known as "Sir Squelchy Jimpot".
>>
>
> Thank goodness for that. I hate custard.
I would just like to say that there is no cabal and that Sir Jim-bob
Squelch-Pants has not been invited.
Thank-you.
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)
Pd
I'm sorry, we haven't time for that just now. Perhaps you could say it
in the weekend when it's not quite so busy?
--
Pd
Jim
> > Thank goodness for that. I hate custard.
>
> I would just like to say that there is no cabal and that Sir Jim-bob
> Squelch-Pants has not been invited.
Look, it's things like that that get rumours started.
Please help save Bletchley Park - sign the petition for
Government funding at: (open to UK residents and ex.pats)
http://petitions.number10.gov.uk/BletchleyPark/ Thank you.
Pd
> So why did it work in one case and not the other? I decided
> to disassemble the Intel binary to find out.
Disassembling binaries to find an error in an Objective-C program is all
of impressive, admirable, awesome, and pretty stupid.
--
Pd
R
> Disassembling binaries to find an error in an Objective-C program is all
> of impressive, admirable, awesome, and pretty stupid.
I had already found the error. But it seemed bizarre the
program had worked at all originally. There was this code
manipulating an object that apparently hadn't been passed
to it. That's why - out of curiosity alone - I disassembled it.
Chris Ridd
I thought the differences between the PPC and x86 Objc-C runtimes were
pretty well documented?
--
Chris
R
reason, can work but shouldn't.
//--- begin code ---
#include <stdio.h>
int square(int x)
{
int y;
y = x * x;
/* Oops! I didn't return y */
}
main()
{
printf("2 squared is %d\n", square(2));
}
//--- end code ---
Save as 'test.c' and compile like so: gcc -o test test.c
When I run it:
sh-3.2$ ./test
2 squared is 4
(gcc version 4.2.1 (Apple Inc. build 5646))
Chris Ridd
> On Thu, 26 Nov 2009 20:24:53 +0000, Chris Ridd <chri...@mac.com>
> wrote:
>
>> I thought the differences between the PPC and x86 Objc-C runtimes were
>> pretty well documented?
>
> They are. I'm not sure why you ask, though!
The registers that callers expect functions to return stuff in is
pretty important. I'm surprised that the compiler didn't warn about
falling out of a function/method without a value though...
--
Chris
R
> The registers that callers expect functions to return stuff in is
> pretty important. I'm surprised that the compiler didn't warn about
> falling out of a function/method without a value though...
Me too. Normally these compilers nag away like mad mothers.
Pd
> A simple example of a program that, for the same
> reason, can work but shouldn't.
And is that for a similar reason, that y is on the stack and read off
even though not explicitly returned?
Some of my best programming was done in Omnis 3, but because it's
obsolete now ( and was obsolete 20 years ago) nobody is ever likely to
come across it, and appreciate quite how clever it was. One of my
favourites was a recursive recipe database for a paint manufacturer,
where he could use a batch of some base he'd made up earlier in another
batch of paint, and it would keep track of all the ingredients through
any number of iterations.
At least I can bask in my own admiration.
--
Pd
Chris Ridd
Perhaps that warning was disabled? Or emitted and just ignored :-(
--
Chris
Rowland McDonnell
> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
>
> ><puzzled> But that's machine time, that is. What's the problem in
> >telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> >Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> >time, but so what? You get four binaries in one.
>
> In an ideal world, yes. And sometimes it's not far off that. But
> often the compilation will fail, or it will succeed but the program
> won't work on the target platform. By accident or design code
> can have architecture specific dependencies that make compiling
> for another platform more involved than simply flicking a switch.
Well, yes - but surely bolting four binaries that are code for *ONE*
platform is not the same as expecting to be able to compile MacOS X code
and have it run on Windoze?
Of course things don't always work smoothly - fact that Intel and
Motorola CPU uses opposite bit ordering is one obvious `issue' I can
think about. But still, the number of apps available as separate
PPC32/PPC64/Intel32/Intel64[1] downloads rather than one universal
binary indicates that developers sort out the problems but choose not to
package the result in the convenient universal binary format from Apple.
Once upon a time, disc space was tight so if one had a fat binary, one
would slim it down. No need for that any more - especially since the
space taken by actual executable code[2] is usually a trivial amount of
the disc space available to any given modern computer.
Rowland.
[1] Erm. I'm presuming Intel 32 bit. I think I might be wrong.
[2] See that huge application package on disc? Look inside. I've got
apps which are apparently huge - until you dig in and notice that most
of the space is taken up by a multilingual manual. Well, I've only got
one like that, but you get the idea.
--
Remove the animal for email address: rowland....@dog.physics.org
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
Rowland McDonnell
> On Thu, 26 Nov 2009 01:46:04 -0000, Rowland McDonnell
> <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > James Dore <james...@new.ox.ac.uk> wrote:
> >
> >> Rowland McDonnell�:
> >>
> >> > R <me...@privacy.net> wrote:
> >> >
> >> >> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell)
> >> wrote:
> >> >>
> >> >> >An open source project that does not supply precompiled binaries is
> >> for
> >> >> >geeks only and is therefore almost certainly a bad open source
> >> project.
> >> >>
> >> >> Not bad.
> >> >
> >> > I think so.
> >> >
> >> >> Just not what you want.
> >> >
> >> > Just not useful for anyone at all, except for the tiny minority of
> >> > computer users who are `in the know' about the required development
> >> > tools which enable them to compile and use this software.
> >>
> >> That's a bit harsh.
> >
> > <puzzled> I think that's a bit wrong of you.
> >
> >> My experience with MacPorts is that it hides most of
> >> that for you.
> >
> > So how can one trust anything, or fix anything that goes wrong, or
> > understand what the hell it's doing to your Mac?
>
> Logs. In the same way that Installer leaves logfiles for you to read via
> Console, you can read the MacPorts logs. Installation occurs witin
> specific portions of the filesystem, *away* from important things eg.
> /Library or /System or /Users. If there are issues with it, you can copy
> and paste a script off the MacPorts site into terminal to nuke the whole
> lot. Normal service is then resumed.
>
> > I daren't use stuff like that, since I want to control what's on my
> > computer and things like MacPorts and Fink take that control away from
> > me, and leave me with - well, I don't know what littering up the `Unixy'
> > directory trees. What would I do if something in that area broke
> > something else? I wouldn't be able to figure anything out at all - this
> > stuff is just not safe for me to use.
> >
> >> You need to download Apple's Developer tools (or install it
> >> from your Mac OS X media) but the procedure is not opaque.
> >
> > Installing that stuff is easy. Learning how to use it is not.
> >
> >> I don't know
> >> one end of XCode from the other,
> >
> > Don't talk crap - you understand a *LOT* about it, far more than I do
> > from looking at it. Oh yeah, you might not know how to use it fully,
> > but you've got a bit of a clue.
>
> Seriously?!
>
> Nope. I am not a programmer. I have not been taught programming, and
> although I would like to learn some, I have much else to do, and frankly,
> it bores me to tears. The only thing I dislike more than programming is
> writing web pages. I can at least understand HTML, a very small bit of PHP
> and some SQL, but I have never opened the Xcode development tools even to
> look at.
>
> > I've got none at all. I've had a
> > developer suggest that I might re-compile some of his software with a
> > minor modification. It's easy to change the code as he suggested - just
> > find the file containing the text that needs changing. But the
> > developer was surprised that I had not a clue how to re-compile the
> > project given that I had the full set of project files and the Apple
> > devtools installed.
> >
> > Well, how could I? You, on the other hand, probably could have figured
> > it out.
>
> Yes, but I'm not special in that regard.
>
> >> but I managed to install it (run the
> >> installer like every other .app) and get MacPorts running with little
> >> practical knowledge of the Developer tools. I haven't had to run
> >> makefiles, or ./configure or whatever else it is that MacPorts does (it
> >> all flashes by too quickly for me to see, although I could probably look
> >> in the logs if I could be arsed).
> >
> > I'm forced to admit that things like MacPorts make stuff that's not been
> > compiled for Macs possible for the brave/foolhardy/ignorant to use. But
> > I don't trust it.
> >
> >> Things were made more simple again when I got PortAuthority (see
> >> <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
> >> and makes it more accessible.
> >
> > I've looked at it. Don't feel able to trust it.
> >
> >> It gave me working copies of nmap and wireshark long before decent OS X
> >> binaries were available; and there are plenty of other useful goodies in
> >> the Audio section.
> >
> > Uhuh. I'm aware that there's stuff available that way that's not
> > available other ways. But I don't see how I can trust it.
>
> Basically, it's been looked at by many other, independent, minds, far more
> clueful than mine. The nature of these things is that if something is
> wrong with the source code, people will spot it, and scream at the
> developer. It's informal peer-review, and the process is not limited to
> the organisation that has produced the code. Generally, this means that
> there is less chance of flaws remaining hidden. True, flaws in source code
> or incorrect function can be exploited by the nefarious more quickly, but
> they have to get their exploits in quick since the developers of the buggy
> code soon have world+dog screaming at them for an update.
>
> >> > The aim is to deny most of us that ability, so that we can be
> >> exploited
> >> > by those who do.
> >>
> >> Sure - it's like maintaining your car. You can do it (and become less
> >> exploited by the car dealerships) if you look into it.
> >
> > No, it's like maintaining your motor vehicle: if you don't do it
> > yourself, you're a suicidal maniac. The professionals cannot be trusted
> > not to kill you. Likewise, with software as with motor vehicles, you
> > cannot trust the `professionals' to do a competent job that won't wreak
> > havoc.
>
> There is some truth in that, but I'd rather trust a specialist to service
> the high-pressure side of my vehicles' diesel engines than me; likewise
> the Aircon systems; and I'd rather have a tyre fitted by a pro than strain
> over it myself for a week. Basic maintenance is doable, but there are jobs
> I need to outsource.
>
> > You can't trust the professionals and you're an idiot if you do - that's
> > my line. Professionals do it for the money. Those professionals who
> > maintain motor vehicles laugh uproariously when they discover that their
> > incompetence has caused another crash on the road - and they say, when
> > you complain `Prove it!' and laugh at your impotent rage some more.
> >
> > I have *scores* of first-hand accounts of that happening.
> >
> > Don't trust a professional motor vehicle mechanic - they're responsible
> > for much death.
>
> Maybe so, and being mildly suspicious is always a good idea, but my
> experience differs from yours; I've not had bad experiences with motor
> services (motor /sales/ are another matter entirely :-) - only one
> noteworthily good I suppose - the TR7 was collected, and they found out
> why it kept misfiring. Turned out that it would destroy rotor arms
> quickly, but not so you could see: The current would earth through the
> supposedly non-conductive rotor arm body down the distributor. Repeatable
> with new rotor arms after a few months driving. New arm on, problem gone,
> but a the old one was measurably conductive. Weird.
>
> >> > Since the aim of providing inaccessible development tools is to deny
> >> > access like that, I'll stick with the idea that it's bad any time a
> >> > software project fails to provide precompiled binaries, because it's
> >> > just a way to deny access to software. And I don't like that.
> >>
> >> You could also look at it as providing access to software that wouldn't
> >> otherwise exist for a particular platform. Developers may not have time
> >> to
> >> build binaries for platforms x, y, and z,
> >
> > <puzzled> But that's machine time, that is. What's the problem in
> > telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> > Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> > time, but so what? You get four binaries in one.
>
> Fine if you're Mac-specific. But source should be able to be complied on
> Mac PPC 32/64 bit, Intel 32/64 bit, Windows 32/64 bit, Linux flavours,
> Solaris flavours, BSD Flavours, IBM AIX flavours, HP-UX flavours, BeOS,
> etc ad nauseam. Much wider target market for the developers without having
> to have a development environment for each (often expensive) platform to
> compile the binaries on. Time could be rented for testing purposes on such
> platforms of course, but often users of these kinds of applications will
> donate that testing in return for credit and favours (new features, early
> updates, etc). Mutual back scratching which benefits all parties.
>
> > Okay, that's an odd example (but normal in the Mac world). But you see,
> > I'm not suggesting that developers should build binaries for everything,
> > just that one expects to see binaries for Windoze and Macs at least,
> > with whatever the maximally convenient packaging for Linux-and-friends
> > OS users happens to be: I assume that Linux+friends have MacPorts-style
> > stuff to make it very very easy to get from source code to `application
> > in use on my computer'.
> >
> >> but providing the source code
> >> allows binaries to be generated for platforms x, y, z, and a, b, c, and
> >> d
> >> as well.
> >
> > Yeah, well, I'm not talking about that, am I?
>
> Maybe not, but that's the model into which MacPorts fits; part of a
> development ecosystem that serves many platforms simultaneously, and with
> little cost to the developer.
>
> >> Mind you, no-one is forcing you to use it, but you're just cutting off a
> >> potentially very useful resource.
> >
> > I'd say I'm cutting off a source of endless trouble.
>
> Given your experiences, perhaps so. Many others have different experiences.
>
> Cheers,
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > I want to use the LAME code for encoding mp3s.
> >
> > I've written that - I'm sure it's what I want.
> >
> > If you think otherwise, then you are wrong.
>
> Let's see now...typing "OSX LAME binary" into Google gave me this
> result: <http://www.macupdate.com/info.php/id/18882>
Let's see now - yes, you're behaving in a deliberately annoying fashion
to get a rise out of me.
> If that doesn't work then you're probably going to have to either
> compile from source,
There's nothing to download. Moreover, I'm a *Mac user* and therefore
do not want a command line anything if I can avoid it - what words there
are around this thing indicate that it's a command line jobbie, and
since the documentation is inadequate, your suggestion would not permit
me to use LAME even if there was anything to download.
> find someone who feels kindly enough to you to
> compile from source for you and give you the binary, or find another
> product.
That advice is deliberately unhelpful and you know it.
You're an arse. Nothing more to be said
Rowland.
Rowland McDonnell
> Rowland McDonnell wrote:
>
> > James Dore <james...@new.ox.ac.uk> wrote:
> >
> >> Rowland McDonnell�:
> >>
> >> > R <me...@privacy.net> wrote:
> >> >
> >> >> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell)
> >> wrote:
> >> >>
> >> >> >An open source project that does not supply precompiled binaries is
> >> for
> >> >> >geeks only and is therefore almost certainly a bad open source
> >> project.
> >> >>
> >> >> Not bad.
> >> >
> >> > I think so.
> >> >
> >> >> Just not what you want.
> >> >
> >> > Just not useful for anyone at all, except for the tiny minority of
> >> > computer users who are `in the know' about the required development
> >> > tools which enable them to compile and use this software.
> >>
> >> That's a bit harsh.
> >
> > <puzzled> I think that's a bit wrong of you.
> >
> >> My experience with MacPorts is that it hides most of
> >> that for you.
> >
> > So how can one trust anything, or fix anything that goes wrong, or
> > understand what the hell it's doing to your Mac?
>
> Logs.
But how do they help you understand? I see a log of diddly-umpteen
files sprayed into whatever directories - wiping out who knows what,
interfering with who knows what else, performing who knows what
functions?
I've looked at that sort of thing, and what I've learnt is that the only
hope one has is that the installer isn't too antisocial and that the
uninstaller is competent, 'cos those bloody logs don't help the normal
user do or understand anything.
> In the same way that Installer leaves logfiles for you to read via
> Console, you can read the MacPorts logs.
Yes, but how can I *understand* what's going on?
> Installation occurs witin
> specific portions of the filesystem, *away* from important things
Or, AIUI, mixed up irrevocably with very important things, mixed up with
my TeX installation and the `thingies' it adds. Or so it seemed when I
looked last with all these things.
> eg.
> /Library or /System or /Users. If there are issues with it, you can copy
> and paste a script off the MacPorts site into terminal to nuke the whole
> lot. Normal service is then resumed.
No, because I'd have none of the things I'd installed that way - and
probably no TeX installation (and other things installed similarly would
be nuke), which would be a major drawback. Or so it seems to me.
> > I daren't use stuff like that, since I want to control what's on my
> > computer and things like MacPorts and Fink take that control away from
> > me, and leave me with - well, I don't know what littering up the `Unixy'
> > directory trees. What would I do if something in that area broke
> > something else? I wouldn't be able to figure anything out at all - this
> > stuff is just not safe for me to use.
> >
> >> You need to download Apple's Developer tools (or install it
> >> from your Mac OS X media) but the procedure is not opaque.
> >
> > Installing that stuff is easy. Learning how to use it is not.
> >
> >> I don't know
> >> one end of XCode from the other,
> >
> > Don't talk crap - you understand a *LOT* about it, far more than I do
> > from looking at it. Oh yeah, you might not know how to use it fully,
> > but you've got a bit of a clue.
>
> Seriously?!
Yes.
> Nope. I am not a programmer. I have not been taught programming,
Not having been taught programming does not make you not a programmer.
> and
> although I would like to learn some, I have much else to do, and frankly,
> it bores me to tears. The only thing I dislike more than programming is
> writing web pages.
Chewing your own eyelids off would probably be worse.
>I can at least understand HTML, a very small bit of PHP
> and some SQL, but I have never opened the Xcode development tools even to
> look at.
Really? Hmm. That surprises me greatly.
> > I've got none at all. I've had a
> > developer suggest that I might re-compile some of his software with a
> > minor modification. It's easy to change the code as he suggested - just
> > find the file containing the text that needs changing. But the
> > developer was surprised that I had not a clue how to re-compile the
> > project given that I had the full set of project files and the Apple
> > devtools installed.
> >
> > Well, how could I? You, on the other hand, probably could have figured
> > it out.
>
> Yes, but I'm not special in that regard.
You are a person of unusual intellect in an environment where that
appears normal. And you know it.
[snip]
> >> Things were made more simple again when I got PortAuthority (see
> >> <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
> >> and makes it more accessible.
> >
> > I've looked at it. Don't feel able to trust it.
> >
> >> It gave me working copies of nmap and wireshark long before decent OS X
> >> binaries were available; and there are plenty of other useful goodies in
> >> the Audio section.
> >
> > Uhuh. I'm aware that there's stuff available that way that's not
> > available other ways. But I don't see how I can trust it.
>
> Basically, it's been looked at by many other, independent, minds, far more
> clueful than mine.
I've noticed that assurances from anyone about the applicability,
reliability, and usefulness of software are almost always false.
These `other independent minds' you refer to - how could their activity
result in me trusting software? What is it that they do which causes
*YOU* to trust software?
I'm very puzzled by this.
> The nature of these things is that if something is
> wrong with the source code, people will spot it, and scream at the
> developer.
The nature of these things is that if there's a problem, the developer
can't be arsed to do anything about it unless it's a problem for him
too. And even then sheer laziness will often cause him to not bother.
That's how it works.
> It's informal peer-review, and the process is not limited to
> the organisation that has produced the code.
The process does not work as you describe---not in the general case,
although I'll admit that freeware authors are more inclined to fix their
software than those who take money for the stuff.
> Generally, this means that
> there is less chance of flaws remaining hidden.
Except that your hypothesis does not appear in my reality: it's not what
I see in the world.
>True, flaws in source code
> or incorrect function can be exploited by the nefarious more quickly, but
> they have to get their exploits in quick since the developers of the buggy
> code soon have world+dog screaming at them for an update.
Yeah, right. I don't see that process.
> >> > The aim is to deny most of us that ability, so that we can be
> >> exploited
> >> > by those who do.
> >>
> >> Sure - it's like maintaining your car. You can do it (and become less
> >> exploited by the car dealerships) if you look into it.
> >
> > No, it's like maintaining your motor vehicle: if you don't do it
> > yourself, you're a suicidal maniac. The professionals cannot be trusted
> > not to kill you. Likewise, with software as with motor vehicles, you
> > cannot trust the `professionals' to do a competent job that won't wreak
> > havoc.
>
> There is some truth in that, but I'd rather trust a specialist to service
> the high-pressure side of my vehicles' diesel engines than me; likewise
> the Aircon systems; and I'd rather have a tyre fitted by a pro than strain
> over it myself for a week. Basic maintenance is doable, but there are jobs
> I need to outsource.
Tyre changing is a job best done by the pros, for sure - they have the
kit. But I've learnt that one must watch them carefully while doing so
and do not trust that they've done the job competently.
I've often intervened when a professional mechanic has been working on
my bike, to stop them doing harm and leaving me with a damaged/dangerous
motorcycle. It's *NORMAL* for me to take such steps. Most often, it's
just cleaning the grit out of a bolt thread that they've put on the
floor, but I've had to do the same to brake parts - and grit in yer
brake hydraulics can very easily be fatal.
(mis-fitted parts is another problem, as is re-using stuff that
shouldn't be re-used)
I've learnt from my own experiences - and the much more harrowing
experiences of others. Professional mechanics are in general a threat
to road safety who must be carefully managed and carefully watched at
all times if you want to avoid sudden death on the road.
I know nothing about working on the high pressure side of a diesel
system; aircon for me is opening my visor.
I'd quite like one of these, sortathing:
<http://www.hdtusa.com/vehicle-m1030-m2.php>
(there's a lot of rah-rah us Yanks are great on that website if you ask
me: the bike is basically a modified Kawasaki motocrosser fitted with a
diesel engine from the boffins at Cranfield over here in Blighty -
again, modified for the particular production technology being used.
"HDT is a recognized leader in light military vehicle innovation." so it
says, as if HDT created the bike in question. Well, it didn't.)
> > You can't trust the professionals and you're an idiot if you do - that's
> > my line. Professionals do it for the money. Those professionals who
> > maintain motor vehicles laugh uproariously when they discover that their
> > incompetence has caused another crash on the road - and they say, when
> > you complain `Prove it!' and laugh at your impotent rage some more.
> >
> > I have *scores* of first-hand accounts of that happening.
> >
> > Don't trust a professional motor vehicle mechanic - they're responsible
> > for much death.
>
> Maybe so, and being mildly suspicious is always a good idea, but my
> experience differs from yours;
Mildly suspicious? MILDLY! Nah, deep seated paranoia and a total
absence of any trust at all, that's what's needed.
> I've not had bad experiences with motor
> services (motor /sales/ are another matter entirely :-)
More than half the time I've paid a professional mechanic to work on my
bike, I've had to make repairs to sort out the damage.
I have a large fund of anecdotes about dangerous mechanicking on
road-going motor vehicles which were given back to the customer in
lethally-dangerous form.
Many of these tales came from the mechanics themselves, and the
mechanics usually - yes, usually - *LAUGH* as they describe the
exploding engines and crashes-due-to-their-incompetence etc.
And I've heard a few of those tales from the customer's point of view as
well as the mechanic's.
There's no way I'd trust a professional mechanic.
> - only one
> noteworthily good I suppose - the TR7 was collected, and they found out
> why it kept misfiring.
<puzzled> That's easy: it was a Triumph TR7, and so cannot be expected
to run reliably. Like an Alfa, yes?
> Turned out that it would destroy rotor arms
> quickly, but not so you could see: The current would earth through the
> supposedly non-conductive rotor arm body down the distributor.
The more I hear about these distributors, the more I wonder why it is
that cars didn't use the motorcycle approach at least for four cylinder
engines. Why not just have two sets of breakers (points, electronic,
whatever) and two coils and spark two pots at once? The cylinder in a
pair that's finishing exhaust won't care, and the other one will fire.
It works brilliantly on, for example, my Honda VF500FII (500cc 4-stroke,
135mph - not bad for a 1984 bike. CDI ignition; no points).
Or four separate spark circuits and four separate coils, with a very
very short HT lead run to the plugs - which is what works brilliantly on
my 1987 VFR750FG.
(or three sets of points and three coils, which is a total bloody
nightmare on 1970s Kawasaki two-stroke triples. I've read about setting
the points...)
> Repeatable
> with new rotor arms after a few months driving. New arm on, problem gone,
> but a the old one was measurably conductive. Weird.
High voltage is always trouble. I gather that in the case of the
materials used for distributors (commonly, anyway), you can get arcing
due to all sorts of odd reasons - and that arcing can leave behind
carbon traces in small cracks in the material. Just one spark, and
you're left with a conductive track. Maybe not all the way, but enough
to cause more arcing as and when: you get the idea.
WD40 is a pretty good palliative in the short term. I'd be inclined to
investigate silicone based coatings and apply something on those lines
to my distributor parts, if I had a car using that arrangement.
> >> > Since the aim of providing inaccessible development tools is to deny
> >> > access like that, I'll stick with the idea that it's bad any time a
> >> > software project fails to provide precompiled binaries, because it's
> >> > just a way to deny access to software. And I don't like that.
> >>
> >> You could also look at it as providing access to software that wouldn't
> >> otherwise exist for a particular platform. Developers may not have time
> >> to build binaries for platforms x, y, and z,
> >
> > <puzzled> But that's machine time, that is. What's the problem in
> > telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> > Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> > time, but so what? You get four binaries in one.
>
> Fine if you're Mac-specific.
Well, yes - but plenty of developers *DON'T* do that, but instead
provide separate downloads.
> But source should be able to be complied on
> Mac PPC 32/64 bit, Intel 32/64 bit, Windows 32/64 bit, Linux flavours,
> Solaris flavours, BSD Flavours, IBM AIX flavours, HP-UX flavours, BeOS,
> etc ad nauseam.
Why? I can understand one expecting to be able to compile code for any
Unix-alike platform, with sufficient expert fiddling, but why expect
that code for (say) Unix-ish-land will also compile on Windoze and BeOS?
> Much wider target market for the developers without having
> to have a development environment for each (often expensive) platform to
> compile the binaries on.
Much wider target for the developers, yes - assuming that by `target'
you mean `reaching other developers who want to port the software to
their platform'. None of this applies to `normal users', does it?
> Time could be rented for testing purposes on such
> platforms of course, but often users of these kinds of applications will
> donate that testing in return for credit and favours (new features, early
> updates, etc). Mutual back scratching which benefits all parties.
Except `ordinary users' just looking for some easy to install software
to install and use.
You seem to forget that I'm a Mac user - and here in Mac-land, it's very
very VERY hard to learn the clever things that one needs to learn to be
able to compile and use software that's not provided in binary form.
> > Okay, that's an odd example (but normal in the Mac world). But you see,
> > I'm not suggesting that developers should build binaries for everything,
> > just that one expects to see binaries for Windoze and Macs at least,
> > with whatever the maximally convenient packaging for Linux-and-friends
> > OS users happens to be: I assume that Linux+friends have MacPorts-style
> > stuff to make it very very easy to get from source code to `application
> > in use on my computer'.
> >
> >> but providing the source code
> >> allows binaries to be generated for platforms x, y, z, and a, b, c, and
> >> d
> >> as well.
> >
> > Yeah, well, I'm not talking about that, am I?
>
> Maybe not, but that's the model into which MacPorts fits; part of a
> development ecosystem that serves many platforms simultaneously, and with
> little cost to the developer.
And little ability for `normal users' to access the software.
> >> Mind you, no-one is forcing you to use it, but you're just cutting off a
> >> potentially very useful resource.
> >
> > I'd say I'm cutting off a source of endless trouble.
>
> Given your experiences, perhaps so. Many others have different experiences.
Yes, that's often said. It's usually said to me in a sneering,
insulting, dismissive fashion to put me down and annoy me.
Maybe I'm just being touchy.
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > James Dore <james...@new.ox.ac.uk> wrote:
> >
> > > Rowland McDonnell�:
> > >
> > > > R <me...@privacy.net> wrote:
> > > >
> > > >> real-addr...@flur.bltigibbet.invalid (Rowland McDonnell) wrote:
> > > >>
> > > >> >An open source project that does not supply precompiled binaries is for
> > > >> >geeks only and is therefore almost certainly a bad open source project.
> > > >>
> > > >> Not bad.
> > > >
> > > > I think so.
> > > >
> > > >> Just not what you want.
> > > >
> > > > Just not useful for anyone at all, except for the tiny minority of
> > > > computer users who are `in the know' about the required development
> > > > tools which enable them to compile and use this software.
> > >
> > > That's a bit harsh.
> >
> > <puzzled> I think that's a bit wrong of you.
> >
> > > My experience with MacPorts is that it hides most of
> > > that for you.
> >
> > So how can one trust anything, or fix anything that goes wrong, or
> > understand what the hell it's doing to your Mac?
> >
> > I daren't use stuff like that, since I want to control what's on my
> > computer and things like MacPorts and Fink take that control away from
> > me, and leave me with - well, I don't know what littering up the `Unixy'
> > directory trees. What would I do if something in that area broke
> > something else? I wouldn't be able to figure anything out at all - this
> > stuff is just not safe for me to use.
> >
>
> OK you asked for precompiled stuff first so it was suggested that
> although Macports is from source it also works like a black box so that
> you do not need the details so that it is very similar to precompiled
> software (Fink does provide precompiled software)
>
> Then you complain that it hides everything - well it doesn't it shows in
> script exactly what it does. Precompiled software tells you nothing of
> what it does - how do you know it is not a trojan, do you know if it
> copies data to a third party? Thus I think you are being inconsistent
> here. If you want to know what a program does exactly and be able to fix
> it then you have to compile form source - see the 'manifestos' for open
> source this being able to fix what happens is given as a main reason for
> open source and why nothing else can be trusted.
>
> > >You need to download Apple's Developer tools (or install it
> > > from your Mac OS X media) but the procedure is not opaque.
> >
> > Installing that stuff is easy. Learning how to use it is not.
> >
> > > I don't know
> > > one end of XCode from the other,
> >
> > Don't talk crap - you understand a *LOT* about it, far more than I do
> > from looking at it. Oh yeah, you might not know how to use it fully,
> > but you've got a bit of a clue. I've got none at all. I've had a
> > developer suggest that I might re-compile some of his software with a
> > minor modification. It's easy to change the code as he suggested - just
> > find the file containing the text that needs changing. But the
> > developer was surprised that I had not a clue how to re-compile the
> > project given that I had the full set of project files and the Apple
> > devtools installed.
> >
> > Well, how could I? You, on the other hand, probably could have figured
> > it out.
> >
> > > but I managed to install it (run the
> > > installer like every other .app) and get MacPorts running with little
> > > practical knowledge of the Developer tools. I haven't had to run
> > > makefiles, or ./configure or whatever else it is that MacPorts does (it
> > > all flashes by too quickly for me to see, although I could probably look
> > > in the logs if I could be arsed).
> >
> > I'm forced to admit that things like MacPorts make stuff that's not been
> > compiled for Macs possible for the brave/foolhardy/ignorant to use. But
> > I don't trust it.
> >
>
> And you trust random executables from the web?
>
> > > Things were made more simple again when I got PortAuthority (see
> > > <http://codebykevin.com> ), which provides a GUI front end for MacPorts,
> > > and makes it more accessible.
> >
> > I've looked at it. Don't feel able to trust it.
> >
> > > It gave me working copies of nmap and wireshark long before decent OS X
> > > binaries were available; and there are plenty of other useful goodies in
> > > the Audio section.
> >
> > Uhuh. I'm aware that there's stuff available that way that's not
> > available other ways. But I don't see how I can trust it.
> >
> > > > The aim is to deny most of us that ability, so that we can be exploited
> > > > by those who do.
> > >
> > > Sure - it's like maintaining your car. You can do it (and become less
> > > exploited by the car dealerships) if you look into it.
> >
> > No, it's like maintaining your motor vehicle: if you don't do it
> > yourself, you're a suicidal maniac. The professionals cannot be trusted
> > not to kill you. Likewise, with software as with motor vehicles, you
> > cannot trust the `professionals' to do a competent job that won't wreak
> > havoc.
> >
> But as you can;t compile software you are trusting professionals here.
>
> > You can't trust the professionals and you're an idiot if you do - that's
> > my line. Professionals do it for the money. Those professionals who
> > maintain motor vehicles laugh uproariously when they discover that their
> > incompetence has caused another crash on the road - and they say, when
> > you complain `Prove it!' and laugh at your impotent rage some more.
> >
> > I have *scores* of first-hand accounts of that happening.
> >
> > Don't trust a professional motor vehicle mechanic - they're responsible
> > for much death.
> >
> > > > Since the aim of providing inaccessible development tools is to deny
> > > > access like that, I'll stick with the idea that it's bad any time a
> > > > software project fails to provide precompiled binaries, because it's
> > > > just a way to deny access to software. And I don't like that.
> > >
>
> No it is beacuse many open source developers want to gove ypu control of
> the software and fix any issues and do not qant to hide things away.
> Like you they distrust 'professionals' so they give you the information
> to do it yourself.
>
> > > You could also look at it as providing access to software that wouldn't
> > > otherwise exist for a particular platform. Developers may not have time to
> > > build binaries for platforms x, y, and z,
> >
> > <puzzled> But that's machine time, that is. What's the problem in
> > telling Apple's dev tools to build binaries for PPC 32 & 64 bit and
> > Intel 32 & 64 bit and wrap 'em all up together? A bit more machine
> > time, but so what? You get four binaries in one.
> >
> > Okay, that's an odd example (but normal in the Mac world). But you see,
> > I'm not suggesting that developers should build binaries for everything,
> > just that one expects to see binaries for Windoze and Macs at least,
> > with whatever the maximally convenient packaging for Linux-and-friends
> > OS users happens to be: I assume that Linux+friends have MacPorts-style
> > stuff to make it very very easy to get from source code to `application
> > in use on my computer'.
> >
>
> > I'd say I'm cutting off a source of endless trouble.
> >
>
> But as you say 'I daren't use stuff like that, since I want to control
> what's on my computer ' and you can ONLY do that if you do your own
> compiles.
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > John Hill <ne...@erewhon.invalid> wrote:
> >
> > > Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
> > >
> > > > John Hill <ne...@erewhon.invalid> wrote:
[snip]
> > > But the current "beta" (Audacity � 1.3.10-alpha-Sep 14 2009 (Unicode))
> > > is stable - even under Snow Leopard - and I have now used it with a USB
> > > deck to transcribe well over a hundred 78s, EPs and LPs...
> >
> > Can you explain what role you used Audacity for in that process? Surely
> > all that's needed is to squirt the RIAA-equalised output from a suitable
> > pre-amp into an A-D converter feeding data into yer Mac somehow?
> >
> > Rowland.
>
> Firstly, as Woody pointed out, you can use LAME with it, and that was
> what you were asking about.
I don't know what that means or in what fashion it ties up with anything
I asked about.
> Secondly, to reply to your last point, I bought a USB deck specifically
> to transcribe the old discs, and Audacity came with it. Evidently the
> deck manufacturer thought it was the best available application to
> accompany it.
Either that, or it was free to provide and made it look like the
manufacturer was providing you with worthwhile goodies to increase the
apparent value of your purchase.
> And the transcription process, to be worth while, is more than just
> squirting the data into the Mac. For 78s (10 and 12 inch) you have to
> get the raw digital data into the Mac, and Audacity does that well.
I do not understand what you are talking about. There is no `raw
digital data' on a 78. It's an analogue signal which just requires the
appropriate equalization applied to it - if you've got a rig intended
for such jobs, it should have a pre-amp with switchable eq curves and
the ability to hack the hardware to produce any custom eq curve you
might like (which isn't at all hard to do, provided you can look up
simple filter networks in a book).
>But
> it is actually recorded at 45 rpm and has to be converted to 78 rpm
What do you mean by that?
> (in
> once case of an old Columbia record, 80 rpm). (EPs and LPs are obviously
> recorded at their correct speed.)
I was under the impression that everything was recorded at the correct
speed.
> After that, for all transcriptions, the file has to be checked for noise
> and as much as possible removed.
Noise can't be removed, not if it's real noise. Clicks and things, yes.
But that's not quite the same as turning the grooves of the record into
a faithful digital copy on a computer.
> (This takes time and care - one 1915
> recording of Caruso was very noisy, but if you try to remove too much
> the quality of what is left is ruined.) Clicks and pops have to be
> removed. In the case of one 1930s 78 disc, which had a crack part-way
> across the disc, the damage had to be repaired. (This takes time and
> patience, and examination of the transcription in minute detail in the
> affected areas.)
>
> A few records had faults that needed attention - needle jump which had
> to be corrected, for example.
>
> Next you have to normalise the recording in the case of mono records,
What do you mean by that?
> and amplify it to some sort of standard level in the case of stereo
> (some recordings are really faint, others boom at you).
That's what you use your pre-amp for prior to digitization - if the
signal level's low when it goes into the A-D converter, you lose dynamic
range and dynamic resolution.
> One or two 78s (Eric Coats's The Three Bears for example) were on two
> sides of a 78 and had to be joined up.
Uhuh.
> Finally you have to divide LPs (and some 78s - Trial by Jury, for
> example) into tracks and name the tracks.
There are many approaches which could do that job.
> You then use Audacity's Export
> Multiple to get someting suitable for iTunes and an iPod. This, at long
> last, is where LAME is used.
Final re-coding.
> Audacity has built-in tools for all of these tasks.
The only time I've looked at Audacity, simple cut-and-paste editing was
too awkward to be practical to use to due the lousy UI.
If it has any abilities beyond that sort of thing, and the ability to
convert between codecs, I've failed to figure out anything at all about
them. It's a lousy bit of work if you ask me - very poor indeed.
> It probably isn't
> the only application that does, but I learned to use enough of it
> (probably less than 10% of its capability) to do what I wanted.
I'm amazed.
> It is
> clearly designed for the serious music user, who will be prepared to
> learn how to use it (and to report problems, which I had to do once -
> the problem was fixed).
No, it's not. I'm a serious type like that, and the UI and
documentation for Audacity is such that it's quite impossible for me to
do anything like that at all.
It's intended for the serious hacker type who can work with badly
written badly implemented inadequately documented shoddy software. A
serious music user wants something a bit better than Audacity.
> All that remains to do in iTunes is to insert the composer and some
> other minor details - whether part of a compilation, disc number and
> group, for example - and see to the artwork (though for the 78s and the
> majority of EPs, there isn't any, unless you can find something
> approprate on the Internet).
>
> Sorry to bang on, but you DID ask!
Umm - yes, and it turns out that Audacity did not do the job of
`transcribing' the data. As I thought, that was done by the pre-amp and
A-D converter hardware.
Rowland.
Rowland McDonnell
> ne...@erewhon.invalid (John Hill) wrote:
[snip]
> >And the transcription process, to be worth while, is more than just
> >squirting the data into the Mac. [huge snip]
>
> I don't expect you'll get any gratitude from Rowland,
Of course, you've got to put some personal abuse in, haven't you?
A thread is not complete without Jamie insulting Rowland just because he
likes doing so.
Why do you do it? Do you enjoy obnoxious behaviour? Or is it a case of
`mud that is flung always sticks'?
Which sort of shittiness are you indulging in, Jamie?
[snip]
Rowland McDonnell
Sod taste - nothing to do with taste. Everything to do with the fact
that even just selecting a region of audio was physically difficult to
do - and never mind anything fancier than that. It's one of the worse
UI's I've ever tried to use in my life.
> It's a Carbon app, and therefore a bit old-fashioned in appearance.
Utterly irrelevant and not something I'd noticed.
> I
> like that, though. I like programs that work with visible files,
> through the Finder, and where all the commands are present on menus and
> have sensible names. I tend to avoid the more modern stuff where
> everything is hidden away from you and you have to use the
> documentation a lot to figure out how to use it.
Audacity needs documentation which is not provided. I tried to figure
out how to use it, and I couldn't - at least, not use it in any
meaningful sense. That's because of the really really *AWFUL* UI and
the worse documentation.
> Like John, I've used Audacity for transcribing and massaging old audio
> material, and I don't think I have ever even looked at the
> documentation. The UI is sufficiently similar to other audio programs
> I've used that it was always very easy to figure out.
>
> I suppose that if you've never used any audio programs before it could
> seem a bit intimidating.
I found it not remotely intimidating - just bloody annoying because it's
so badly implemented.
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > > > How do they? Most open source software projects are one or two people,
> >
> > In which case, it's not what I'd call an open source software project.
> > The open source software I use isn't made by `one or two people'.
> > Firefox, LaTeX, and so on - all huge projects.
>
> 'Open source' has nothing to do with the number of people working on the
> project.
If the group of people working on the project is /in effect/ a small
closed group, then it's not an open source project in reality no matter
what the licencing basis etc.
That's what I'm talking about.
Rowland McDonnell
> Rowland McDonnell <real-addr...@flur.bltigibbet.invalid> wrote:
>
> > But they don't want to do it because it would let people who are not of
> > the aristocracy use their software - the *reason* for refusing to
> > provide precompiled binaries is to ensure that only software developers
> > (a tiny minority) can use the software.
> >
> > They want to deny the use of their software to most people - don't ask
> > me why, but it's what they're up to.
>
> This is so wrong it's hard to know where to begin.
But it's right - it's hard to know how to get you to see it.
> Look, we get that you personally don't like compiling stuff from source
> because you feel that you, personally, can't. Fine. But to claim it's
> all part of some shadowy technological intelligencia is just silly.
To suggest that I've made any such suggestion is just plain insulting.
Rowland McDonnell
[snip]
> Max uses LAME as the MP3 encoder. It's simple enough to work.
> http://sbooth.org/Max/
Now then Jamie, you could have suggested that to me directly.
But the only replies to me that I've seen from you in this thread which
are directed at me have been personal abuse directed at me.
Odd, that - what makes you behave so shittily?
Rowland McDonnell
[snip]
> Further, the general tenor of unix (and perl) is that docs are written
> by "gurus" for "newbies",
No, docs are written by gurus for gurus, and newbies can go fuck
themselves if they don't like it.
> who had better remember their place in the
> scheme of things. This is evidenced by the often rude reception to
> "newbies" who blunder uninvited into some of the technical NGs.
No, you always get buckets of abuse unless you're a stone cold expert.
I've been told, after objecting to such behaviour, that technical forums
permit the experts to behave rudely towards tyros as a matter of course
and it's perfectly acceptable and normal.
Fuck that.
[snip]
> By contrast the PHP docs are written by intelligent adults for
> intelligent adults, another reason that I prefer to use it.
Hmm.
Okay, a hint of attraction there.