On 5 Aug 2010, at 16:03, Mark Cerqueira wrote:

I think you're referring to the instructions posted here:

http://chuck.cs.princeton.edu/doc/build/

The person from Apple you spoke with was "kind of" right. Any time you type sudo in the terminal, you could potentially cause some serious damage. That said, if you copy the commands posted on that page exactly, you won't have any problems.

In addition, stuff that does not belong to the system installation should normally be in /usr/local/. But it is a good idea to make sure to have a backup before trying 'sudo', so that it can be restored.

On 5 Aug 2010, at 21:52, Stefan Blixt wrote:

I run chuck from the command line without having followed those instructions - I didn't do any of that dangerous sudo stuff, I just added the place where I put the chuck binary in my path by editing .profile.

Even that might be too complicated to those that do not know about Unix stuff. But one can put in the directory where the file is, and run it using './chuck <file>'. On a Mac, one can put it into / Applications/ and run it with /Applications/chuck. But I suspect that some things won't work properly without root permissions - probably Internet stuff.

Having said that, it's definitely not an easier way to do it. Couldn't there have been a better installer for chuck that does all of this automatically, just requiring the user to enter a password at the proper time? Saying "enter password" instead of "now we're going to modify your terminal" feels more... diplomatic.

That would be better.

It's curious, I've gotten so used to roaming around unix systems, doing all kinds of crazy stuff. It's good to be reminded now and then that opening .profile with vi (.profile isn't visible in Finder), and adding stuff to the PATH variable isn't a very obvious thing to do.

Fink also adds a line to .profile, if it is not already in the search path.

Thinking about how MacOS got slammed on top of FreeBSD still cracks me up.

That was how it began, but now it is certified UNIX. BSD is not. So it has departed considerably.

Perfectly logical, but oh how confusing when you come from a Unix background.

What is confusing?

Some programs may need installed as root if they call something else even if it isn't run as root. Or so I thought. The permissions of the user are though stamped onto the process. On 5 Aug 2010, at 22:30, Stefan Blixt wrote:

I'm not running ChucK with root privileges to my knowledge. Sound and UDP communication shouldn't require root access.

/Stefan

On 6 Aug 2010, at 13:33, Kassen wrote:

...

The installation instructions I downloaded say to reconfigure the terminal of a Mac but the Apple people I consulted advised me not to do that. They say reconfiguring the terminal is outside the warrantee and they see it as potentially destroying the computer!

I heard of this before, but it's -to put it bluntly- nonsense. You can't really "destroy a computer" by reconfiguring some files. What can happen is that you get enthusiastic, start experimenting late at night and go too far, making the computer unable to boot. Then you re-install the OS; many tinkering Linux people did that once or twice. The hardware will stay totally fine.

Actually, this is not the case on later Mac models, as the OS controls the fan cooling system. So you can really destroy the Mac by overheating it. I think it may have happened to a MacBook Air here - there were problems with the software in earlier models. Suddenly, it would no more reboot. It happened on a very hot day. Eventually, the motherboard, or something had to be replaced. One can also destroy the Mac by making a poorly written KEXT (kernel extension). It is too slow to let all stuff run as programs, so one can make an extension to the kernel itself, running without the normal kernel checks then. If it sabotages the kernel, then the cooling system may not run properly. I'm not sure this has happened, but it is a theoretical possibility, in fact mentioned on the Darwin-kernel list.

On 6 Aug 2010, at 23:17, Kassen wrote:

...

Actually, this is not the case on later Mac models, as the OS controls the fan cooling system. So you can really destroy the Mac by overheating it. I think it may have happened to a MacBook Air here - there were problems with the software in earlier models. Suddenly, it would no more reboot. It happened on a very hot day. Eventually, the motherboard, or something had to be replaced.

Yes, there will be exceptions, on specific models under unusual conditions, ...

I think it is all recent models.

...I believe there have also been some hard-drives that could be destroyed by software commands in the recent past.

The later laptops have an accelerometer that locks the hard-drive if you drop it. ANd the batteries, too, are controlled by the OS.

However that's A) rare and B) not a issue with the terminal as such.

No, it is 'sudo'...

Though it might be possible I wouldn't know how to address the fan speed through Bash here&now.

...in combination with something that messes up the OS.

...

One can also destroy the Mac by making a poorly written KEXT (kernel extension). It is too slow to let all stuff run as programs, so one can make an extension to the kernel itself, running without the normal kernel checks then. If it sabotages the kernel, then the cooling system may not run properly. I'm not sure this has happened, but it is a theoretical possibility, in fact mentioned on the Darwin-kernel list.

No doubt that's true... but that definitely wouldn't happen by accident...

Some newbies want to write KEXTs as they write other programs, and ask how they van intercept the kernels normal work...

...and I also feel that that is the kind of design error that a warranty should cover, certainly in the case of computers sold as a matched pair of a OS and hardware.

If it happens within the warranty period.

Normal use of the terminal, ...

The problem is that it takes a bit to only do what is "normal".

...including the installation of languages like ChucK should -and will- be perfectly safe and normal usage of a computer.

Even the installation instruction of chuck isn't normal, since it says to put it in /usr/bin/ instead of /usr/local/bin/. A guy how works on the UNIX standard, and probably has his own variation, was shocked when a GNU/Linux user modified stuff there. This probably won't toast you Mac in the literal sense:-), but there are folks out there are modifying the systems installation.

On 7 Aug 2010, at 10:27, Kassen wrote:

However that's A) rare and B) not a issue with the terminal as such.

No, it is 'sudo'...

Ok.

Sorry, it was a rhetorical agreement, same as "yes". Ambiguous, like in this video: http://www.youtube.com/watch?v=6JrIYR8jArk

However, sudo is a tool to protect the installation against unauthorised modifications.

Actually, not: it is just a shortcut to become root; try 'sudo -s'. Though restrictions can be implemented, that is not so in Mac OS X. In addition, when one does a 'sudo', it is valid for a few minutes, which can be exploited by malware, by trying every minute if the user has enabled root permissions.

Wherever this directory is; its normal that all executables are kept in a certain directory and that sudo is needed to mark a file as executable and place it there. Sudo isn't -imho- the right tool to either protect the hardware against damage or support personnel from tricky questions.

On the other hand, whenever you install something on Mac OS X, and is asked for the password, one is in effect doing the same thing as a 'sudo', becoming root. So one should never do that unless one trust the software.

If we look here; http://www.apple.com/macosx/what-is-macosx/core-foundation.html

We read; UNIX power users will feel at home in Darwin, the robust BSD environment ...

FYI: Though it derives from FreeBSD, it is now certified UNIX (Intel 1.5 and later).

...that underlies Mac OS X and is accessible from the Terminal application. All of the common UNIX utilities, command shells, and scripting languages are included in Mac OS X, including Perl, PHP, tcl, Ruby, and Python. And Mac OS X provides a set of optimized libraries, making it easy to port your existing UNIX code.

To me that sounds at odds with claiming that Edward here can't install ChucK without voiding his warranty.

I think there was a confusion in the communications, since he went and asked them in the first place. :-)

Yes; sudo could damage stuff, but then so can cars, claw-hammers and kitchen-knives. That doesn't meant we should abstain from driving, carpentry and cooking.

Yes, I was independently think about the kitchen-knife analogy. And as noted above, people in effect do a 'sudo' whenever they install something requiring a password. This includes frequent system updates.

Instead I'd suggest that Edward either stick to the installation instructions or look into one of the many books or online tutorials about the bash terminal; there are even quite a few aimed specifically about bash in a OSX context.

I suspect he has absolutely no knowledge about the console (Terminal). Therefore, to start with it, it might be safest to put it into ~/bin/. It is good with this discussion - ChucK with strange downloading comments, is directed to the console-savvy user, in effect shutting others out.

On 7 Aug 2010, at 14:27, Kassen wrote:

...

...

However, sudo is a tool to protect the installation against unauthorised modifications.

Actually, not: it is just a shortcut to become root; try 'sudo -s'.

Quite so, and I believe that unlike with becoming root outright the commands given with sudo are logged, which can be helpful to trace what went wrong, if something does.

There is a file /private/etc/sudoers which can be edited with 'visudo' to put restrictions. But the user does become root. I think all stuff is logged - there is a Console showing it, if you so like.

...

Though restrictions can be implemented, that is not so in Mac OS X. In addition, when one does a 'sudo', it is valid for a few minutes, which can be exploited by malware, by trying every minute if the user has enabled root permissions.

It might be preferable to restrict root access to a single bash session, or perhaps to require it for every command. System-wide root access sounds a bit excessive to me, but I don't know what considerations went into that choice.

Yes, one can turn the timing off, and some do. Otherwise, giving access in just the place where one wrote it might have been wise, but one can do it in one window, and then do it in another without switching.

...

On the other hand, whenever you install something on Mac OS X, and is asked for the password, one is in effect doing the same thing as a 'sudo', becoming root. So one should never do that unless one trust the software.

Good advice. I do trust our devs, even though they can be a bit chaotic at times ;-) ..

It is mostly important when you visit porn sites - don't give your password away there! Strange that one would have to give such advice. :-)

...

FYI: Though it derives from FreeBSD, it is now certified UNIX (Intel 1.5 and later).

It is. Of course the main thing that this indicates is that Apple (unlike some other *nixes) has a budget for certification.

Yes, but I saw that there are efforts to close in on the free variations.

...

I suspect he has absolutely no knowledge about the console (Terminal). Therefore, to start with it, it might be safest to put it into ~/bin/.

It is good with this discussion - ChucK with strange downloading comments, is directed to the console-savvy user, in effect shutting others out.

Yes. There have been a lot of questions about this. Commandline interfaces do look alien and a bit scary to many. Perhaps we should spend some time on this in a FAQ, for example with a link to a good online tutorial. We may also need to update the docs on the mini since the mini really isn't all that experimental and dangerous any more.

An installer might put the stuff into /usr/local/bin where it should be.

It's not that hard to make a .pkg Installer file. Maybe this is the "right thing" to do for folks who would like to have ChucK installed but nnot have to type commands into the Terminal to do it, but who'd like to be able to use the Terminal to just run ChucK. I'll take a look at this this evening; shouldn't be all that difficult.

On 11 Aug 2010, at 06:08, Tom Lieber wrote:

...

It's not that hard to make a .pkg Installer file. Maybe this is the "right thing" to do for folks who would like to have ChucK installed but nnot have to type commands into the Terminal to do it, but who'd like to be able to use the Terminal to just run ChucK.

I'll take a look at this this evening; shouldn't be all that difficult.

You're right, it wasn't! I used the PackageMaker GUI. I did get stuck trying to make a symlink in /usr/local/bin/ to the chuck binary, though, so it's not that useful..

The normal would be the opposite: the miniAudicle has a pre-made symlink to /usr/local/bin/chuck. Then, when the latter is updates, miniAudicle will use it. If for some reason, one does not want miniAUdicle to change, just let it have a binary as is the case now. One will then run different binaries in it and from the console.

On Thu, Aug 12, 2010 at 8:32 PM, Tom Lieber wrote:

<snip> I'm not quite sure what you're saying, but if miniAudicle installs a ChucK in /usr/local/bin, then I don't see a reason to have a separate package just for command-line ChucK.

The command-line version of Chuck iterates a while before the one in miniAudicle catches up. Sometimes a while goes by and you're using the latest chuck on the command-line and the previous one in miniAudicle. That's one reason. But I don't think that miniAudicle puts a binary of chuck in /usr/local/bin, I think it keeps it's own binary as part of the .app file package, which is where that binary belongs. I'm not sure what the story is with how miniAudicle gui communicates with the chuck process, but it's possible that it's version of chuck is modified to accomodate that. Spencer? -Mike

-- Tom Lieber http://AllTom.com/ http://favmusic.net/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

It may cause incompatibilities, like the bug mentioned earlier where miniAudicle code can't start with a C comment. On 24 Aug 2010, at 20:51, Spencer Salazar wrote:

Hey, its my name! Catching up on email after a few weeks off-grid...

miniAudicle links directly to the source code that produces the chuck command line binary, to allow a much tighter level of integration with chuck's internals than is possible with the standard chuck command line binary. So in this sense, miniAudicle doesn't have its own chuck binary in the .app package, nor does it install anything to the usual $PATH directories. Its all a single binary (GUI + chuck).

spencer

hi dear. A simply ,but a problem... please give advice something. It's problem a settlement of connect with "Wii controller" at Chuck prg. Also, I think that be able to play like mousePad or than more. For Example::miniAudicle/examples/hid/mouse-fm.ck I try call up that's file exchanges codes for Wii controller with trackpad. "Wii controller" has the coordinates x, y, z, respectively "freq, fm mod, filter freq" Why do not synchronize the "Theremin" and play like "beat box" of the new devices can be used as I think the idea. Wii controller is coneccted from "DarwiinRemote" http://darwiin-remote.sourceforge.net/ In addition to "Chuck" and "Wii remote device" if it please share how to connect directly. /takashi

Andy. Thank you for advice. "OSC" field, so we should still study for me, if possible we want a good well customized. best. //takashi On 2010/08/14, at 0:29, Andrew Turley wrote:

Unfortunately the Wii controller cannot be accessed as an HID device. One option for using the Wii controller with Chuck is a program called OSCulator (http://www.osculator.net/). It translates messages from the Wii controller (and other devices, too) into OSC messages. You can then write a Chuck program that responds to these OSC messages.

andy

2010/8/13 田岡 卓 :

...

hi dear. A simply ,but a problem... please give advice something. It's problem a settlement of connect with "Wii controller" at Chuck prg. Also, I think that be able to play like mousePad or than more. For Example::miniAudicle/examples/hid/mouse-fm.ck I try call up that's file exchanges codes for Wii controller with trackpad. "Wii controller" has the coordinates x, y, z, respectively "freq, fm mod, filter freq" Why do not synchronize the "Theremin" and play like "beat box" of the new devices can be used as I think the idea. Wii controller is coneccted from "DarwiinRemote" http://darwiin-remote.sourceforge.net/ In addition to "Chuck" and "Wii remote device" if it please share how to connect directly. /takashi _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

タオカタカシ digitaltaokatakashi@mac.com