I recently decided to make the leap from Yellow Dog Linux to Mac OS X on myTitanium PowerBook. Getting everything to work the way I wanted proved to be achallenge, but well worth it. This document outlines all that I learned, so thatneither you nor I will have to experience such pain again. The overall goal wasto get Bricolage up and running, figuring that if it worked, then just aboutany mod_perl based solution would run. I'm happy to say that I was ultimatelysuccessful. You can be, too.
In the descriptions below, I provide links to download the software you'll need,as well as the shell commands I used to compile and install each package. In allcases (except for the installation of the Developer Tools), I saved eachpackage's sources to /usr/local/src and gunzipped and untarred them there. Ialso carried out each step as root, by running sudo -s. If you're notcomfortable using a Unix shell, you might want to read up on it, first. All ofmy examples also assume a sh-compatible shell, such as bash or zsh. Fortunately,zsh comes with OS X, so you can just enable it for yourself in NetInfo Managerby setting users -> -> shell to '/bin/zsh', where isyour user name.
Universal music theory library for iOS, iPadOS, macOS, tvOS and watchOS in Swift - cemolcay/MusicTheory. Showing posts with label Mac OS X Snow Leopard. Wednesday, November 9, 2016. Catalan number (1) Catalysis (1) Category theory (1) Causal graph (2). Showing posts with label Mac OS X Snow Leopard. Showing posts with label Mac OS X Snow Leopard. Wednesday, November 9, 2016. MacBook 2,1 (2007): Mac OS X Snow Leopard: Installing rEFInd. Analytic number theory (1) Anamorphic format (1) Anatomy (1). This entry was posted on Friday, June 2nd, 2006 at 5:47 pm and is filed under Hardware, Mac OS, Software. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. Ghost Theory is a single-player horror adventure game focusing on stealth and exploration. Using a range of ghost hunting gadgets and abilities, you must investigate real world haunted places to reveal the truth behind their haunting, all the while evading the wrath of their.
Developer Tools
All of the software that I describe installing below must be compiled. Tocompile software on Mac OS X, you need to install the Mac OS X Developer Tools.These provide the cc compiler and many required libraries. Conveniently, thesecome on a CD-ROM with the Mac OS X Version 10.1 upgrade kit. I just popped inthe CD and installed them like you'd install any other OS X software. I neededadministrative access to OS X to install the Developer Tools (or, indeed, toinstall any of the other software I describe below), but otherwise it posed noproblems.
The best time to install the Developer Tools is immediately after upgrading toOS X version 10.1. Then run the Software Update applet in the System preferencesto get your system completely up-to-date. By the time I was done, I had thesystem updated to version 10.1.3.
Emacs
The first step I took in the process of moving to OS X was to get working thetools I needed most. Essentially, what this meant was GNU Emacs. Now I happento be a fan of the X version of Emacs – not XEmacs, but GNU Emacs with Xsupport built in. I wasn't relishing the idea of having to install X on OS X(although there are XFree86 ports that do this), so I was really pleased todiscover the Mac-Emacs project. All I had to do was patch the GNU Emacs 21.1sources and compile them, and I was ready to go! GNU Emacs works beautifullywith the OS X Aqua interface.
There were a few configuration issues for me to work out, however. I have becomeaddicted to the green background that an old RedHat .XConfig file had set, and Iwanted this feature in OS X, too. Plus, the default font was really ugly (well,too big, really – anyone know how to make it smaller in Emacs?) and the Maccommand key was working as the Emacs META key, rather than the option key. So Ipoked around the net until I found the settings I needed and put them into my.emacs file:
Installing Emacs is not required for installing any of the other packagesdescribed below – it just happens to be my favorite text editor and IDE. So Idon't provide the instructions here; the Mac-Emacs project does a plenty goodjob. If you're not comfortable with Unix editors, you can use whatever editoryou like. BBEdit is a good choice.
GDBM
Mac OS X doesn't come with a DBM! But since mod_ssl needs it, we have toinstall it. Fortunately, I found this PDF detailing someone else's adventureswith mod_ssl on OS X, and it provided decent instructions for installing GDBM.First, I created a new user for GDBM. In NetInfoManager, I created a duplicateof the 'unknown' user and named it 'bin'. Then, I downloaded GDBM from theFSF, and installed it like this:
That did the trick. Nothing else was involved, fortunately. Sleep tight (itch) mac os.
Expat
Who doesn't do something with XML these days? If your answer is, 'not me!', thenyou'll need to install the Expat library in order to work with XML::Parser inPerl. Fortunately it's relatively easy to install, although support for the-static flag appears to be broken in cc on OS X, so it needs to be stripped out.I downloaded it from its project bpage, and then did this:
Perl
Although Mac OS X ships with Perl (Yay!), it's the older 5.6.0 version.There have been many bug fixes included in 5.6.1, so I wanted to make sure I gotthe latest stable version before I built anything else around it (mod_perl,modules, etc.).
Being a Unix program, Perl doesn't expect to run into the problems associatedwith a case-insensitive file system like that Mac OS X's HFS Plus. So there area couple of tweaks to the install process that make it slightly more complicatedthan you would typically expect. Fortunately, many have preceded us in doingthis, and the work-arounds are well-known. Basically, it comes down to this:
There were a few errors during make test, but none of them seems to besignificant. Hopefully, in the next version of Perl, the build will work just asit does on other platforms.
Downloads
Before installing Open SSL, mod_ssl, mod_perl, and Apache, I needed to get allthe right pieces in place. The mod_ssl and mod_perl configure processes patchthe Apache sources, so the Apache sources have to be downloaded and gunzippedand untarred into an adjacent directory. Furthermore, the mod_ssl versionnumber corresponds to the Apache version number, so you have to be sure thatthey match up. Normally, I would just download the latest versions of all ofthese pieces and run with it.
However, Bricolage requires the libapreq library and its supporting Perlmodules to run, and these libraries have not yet been successfully ported toMac OS X. But worry not; fearless mod_perl hackers are working on the problemeven as we speak, and there is an interim solution to get everything working.
As of this writing, the latest version of Apache is 1.3.24. But because I neededlibapreq, I had to use an experimental version of Apache modified tostatically compile in libapreq. Currently, only version 1.3.23 has been patchedfor libapreq, so that's what I had to use. I discovered this experimental paththanks to a discussion on the Mac OS X Perl mail list.
So essentially what I did was download the experimental apache.tar.gz and theexperimental lightweight apreq.tar.gz packages and gunzip and untar them into/usr/local/src. Then I was ready to move on to Open SSL, mod_ssl, andmod_perl.
Open SSL
Compiling Open SSL was pretty painless. One of the tests fails, but it all seemsto work out, anyway. I download the sources from the Open SSL site, and didthis:
mod_ssl
The mod_ssl Apache module poses no problems whatsoever. I simply downloadedmod_ssl-2.8.7-1.3.23 from the mod_ssl site (note that the '1.3.23' at theend matches the version of Apache I downloaded) and gunzipped and untarred itinto /usr/local/src/. Then I simply excuted:
mod_perl
Configuring and installing mod_ssl was, fortunately, a relativelystraight-forward process. Getting Apache compiled with mod_perl and mod_ssl,however, was quite tricky, as you'll see below. A number of braver folks than Ihave preceded me in installing mod_perl, so I was able to rely on theirhard-earned knowledge to get the job done. For example, Randal Schwartz postedinstructions to the mod_perl mail list, and his instructions worked well forme. So I downloaded the sources from the mod_perl site, and did this:
Apache
Getting Apache compiled just right was the most time-consuming part of thisprocess for me. Although many had gone before me in this task, everybody seemsto do it differently. I had become accustomed to just allowing Apache to usemost of its defaults when I compiled under Linux, but now I was getting allkinds of errors while following different instructions from differentauthorities from around the web. Sometimes Apache wouldn't compile at all, andI'd get strange errors. Other times it would compile, pass all of its tests, andinstall, only to offer up errors such as
when I tried to start it. It turns out that the problem there was that I had anumber of modules compiled as DSOs – that is, libraries that can be loaded intoApache dynamically – but wasn't loading them properly in my httpd.conf. Thiswas mainly because I've grown accustomed to Apache having all the libraries Ineeded compiled in statically, so I simply didn't have to worry about them.
But I finally hit on the right incantation to get Apache to compile witheverything I need added statically, but still with support for DSOs by compilingin mod_so. Gojoe mac os. I present it here for your viewing pleasure:
This series of commands successfully compiled Apache with mod_perl and mod_sslsupport statically compiled in, along with most of the other default modulesthat come with Apache. In short, everything is there that you need to run amajor application with security such as Bricolage.
Note that make certificate will lead you through the process of creating anSSL certificate. I like to use the 'custom' type so that it reflects the name ofmy organization. But you can use whatever approach you're most comfortable with.Consult the mod_ssl INSTALL file for more information.
libapreq
Once Apache is installed with mod_perl and mod_ssl, the rest is gravy! Theexperimental libapreq library I downloaded installed without a hitch:
Thery Mac Os Catalina
PostgreSQL
PostgreSQL is a sophisticated open-source Object-Relational DBMS. I use it alot in my application development, and it, too, is required by Bricolage. I wasa bit concerned about how well it would compile and work on Mac OS X, but Ineedn't have worried. First of all, Apple has provided some pretty decentinstructions. Although they mainly document how to install MySQL, acompeting open-source RDBMS, many of the same concepts apply to PostgreSQL.
The first thing I had to do was to create the 'postgres' user. This is thesystem user that PostgreSQL typically runs as. I followed Apple's instructions,using NetInfo Manager to duplicate the default 'www' group and 'www' user andgive the copies the name 'postgres' and a new gid and uid, respectively.
Next I downloaded the PostgreSQL version 7.2.1 sources. Version 7.2 is the firstto specifically support Mac OS X, so going about the install was as simple as itis on any Unix system:
That was it! PostgreSQL was now installed. Next I had to initialize thePostgreSQL database directory. Again, this works much the same as it does on anyUnix system:
The final step was to start PostgreSQL and try to connect to it:
Wizbet no deposit codes. If you follow the above steps and find yourself at a psql prompt, you're inbusiness! Because I tend to use PostgreSQL over TCP, I also enabled TCPconnectivity by enabling the 'tcpip_socket' option in the postgresql.conf filein the data directory created by initdb:
If you're like me, you like to have servers such as PostgreSQL start when yourcomputer starts. I enabled this by creating a Mac OS X PostgreSQL startupbundle. It may or may not be included in a future version of PostgreSQL, but inthe meantime, you can download it from here. Simply download it, gunzip anduntar it into /Library/StartupItems, restart OS X, and you'll see it start upduring the normal Mac OS X startup sequence. I built this startup bundle byborrowing from the existing FreeBSD PostgreSQL startup script, the Apachestartup script that ships with OS X, and by reading the Creating SystemStarterStartup Item Bundles HOWTO.
XML::Parser
At this point, I had most
of the major pieces in place, and it was time for me to install the Perl modulesI needed. First up was XML::Parser. For some reason, XML::Parser can't findthe expat libraries, even though the location in which I installed them ispretty common. I got around this by installing XML::Parser like this:
Text::Iconv
In Bricolage, Text::Iconv does all the work of converting text betweencharacter sets. This is because all of the data is stored in the database inUnicode, but we wanted to allow users to use the character set with whichthey're accustomed in the UI. So I needed to install Text::Iconv. Naturally, MacOS X doesn't come with libiconv – a library on which Text::Iconv depends – soI had to install it. Fortunately, it was a simple process to download it anddo a normal build:
Now, Text::Iconv itself was a little more problematic. You have to tell it tolook for libiconv by adding the -liconv option to the LIBS key in Makefile.PL.I've simplified doing this with the usual Perl magic:
DBD::Pg
Although the DBI installed via the CPAN module without problem, DBD::Pgwanted to play a little less nice. Of course I specified the proper environmentvariables to install it (anyone know why DBD::Pg's Makefile.PL script can't tryto figure those out on its own?), but still I got this error during make: New free slot machines.
But this was one of those unusual situations in which the error message washelpful. So I took the error message's advice, and successfully compiled andinstalled DBD::Pg like this:
Thery Mac Os X
LWP
The last piece I needed to worry about customizing when I installed it wasLWP. Before installing, back up /usr/bin/head. The reason for this is that LWPwill install /usr/bin/HEAD, and because HFS Plus is a case-insensitive filesystem, it'll overwrite /usr/bin/head! This is a pretty significant issue, sincemany configure scripts use /usr/bin/head. So after installing LWP, move/usr/bin/HEAD, GET, & POST to /usr/local/bin. Also move /usr/bin/lwp* to/usr/local/bin. Then move your backed-up copy of head back to /usr/bin.
Naturally, I didn't realize that this was necessary until it was too late. Iinstalled LWP with the CPAN module, and it wiped out /usr/bin/head. Fortunately,all was not lost (though it took me a while to figure out why my Apache compileswere failing!): I was able to restore head by copying it from the Mac OS Xinstaller CD. I Just popped it in an executed the command:
And then everything was happy again.
Bricolage
And finally, the pièce de résistance: Bricolage! All of the otherrequired Perl modules installed fine from Bundle::Bricolage:
Then I simply followed the directions in Bricolage's INSTALL file, and started‘er up! I would document those steps here, but the install process is currentlyin flux and likely to change soon. The INSTALL file should always be current,however – check it out!
To Be Continued
No doubt my adventures with Unix tools on Mac OS X are far from over. I'vereported to various authors on the issues I've described above, and most willsoon be releasing new versions to address those issues. As they do, I'llendeavor to keep this page up-to-date. In the meantime, I am thoroughly enjoyingworking with the first really solid OS that Apple has released in years, andthrilled that I can finally have the best of both worlds: a good, reliable, andelegant UI, and all the Unix power tools I can stand! I hope you do, too.
Looking for the comments? Try the old layout.
I've been playing around with the new Mac OS X Lion 'file versioning' facility. Ars Technica as usual provides an insightful and detailed explanation of this new feature; Krypted.com provides further low-level details (but, see below).
File versioning is, essentially, a consumer-level and user-friendly version control system. Coupled with Lion's new autosaving functionality, it aims to change and hopefully simplify the way users think about documents. For example, as you type your Pages or TextEdit document, you don't need to worry about explicitly saving your work: Lion does this for you every once in a while, when you quit the app, or when some other event occurs that requires the system to preserve your work so far. For instance, you can email the document you are working on without first saving it, because Lion does it for you (so what you are sending is exactly what you have written so far). The bottom line is that, ideally, the user should never worry about losing her work. Saving is now a logically distinct operation: it means that the document is currently in a state that the user wants to preserve for possible future reference, even though she may want to continue editing it. Hence, the semantic change in the corresponding entry in the File menu: 'Save a version.' If you use a version control system, consider this: 'saving' a file just preserves the changes you've made, whereas 'commiting' a file to a repository makes sure that, should further edits introduce bugs, you can always roll back to working code. In Lion, 'saving-as-preserving' happens automatically, whereas 'saving-as-committing' requires explicit user intervention, as it should.
Both autosaving and versioning are application-level, not system-level features: that is, they must be supported by each individual applications. This is similar to other Lion features, such as full-screen mode. As you will see, I think this is a very good thing, because—in my opinion—these features do not necessarily make sense for all applications, or in all circumstances. On the other hand, this raises an important question: how do these features interact with traditional file access, be it command-line or Finder-based, or simply via non-versioning apps? If you use Dropbox, this question is relevant: what exactly gets synchronized? Indeed, Dropbox is essentially a fancy front-end to the rsync utility, which I use directly for my work backups (in addition to Dropbox); again, how do versioning and autosaving interact with it?
Autosaving does not present any problems in this respect: once a file is named, further changes are saved just as if the user was a compulsive CMD-S hitter (that is, me). So, rsync and friends work just fine; there are some subtleties related to accessing a file with both a versioning and a non-versioning app, but nothing that interferes with usage: see below for details. The situation for file versioning is a bit more complicated. To investigate possible adverse effects, I had to explore the implementation of this feature. There is some information on the Internet (again, see the aforelinked articles), but a lot of details are missing, and I should warn you that I myself did not go very far—although I did uncover a few interesting tidbits. In case you are wondering, the publicly accessible Apple developer documentation has essentially zero implementation information about file versioning. For all practical purposes, Apple wants you to treat this feature as a black box.
First, the bottom line: file-level access is not hindered in any way by file versioning either. You can continue using Dropbox, rsync, or more generally any non-versioning app, and you will get pretty much the same functionality in Lion as you did in Snow Leopard. This is excellent news. On the other hand, changes made to a file using any non-versioning app will not be versioned by the operating system: again, versioning is an application-level feature, not something that is enforced by the OS. This is probably good, although it does mean that, as far as I can tell, there is no easy way to, for instance, back up versions of a file using rsync (except in a rather inefficient way). Now for the details. This post describes how accessing files with both versioning and non-versioning apps might work from a user, or app perspective; in the next, I turn to some low-level details I was able to uncover, and that I haven't seen explained elsewhere (but, feel free to provide references if you find them).
Interacting with non-versioning apps: UI considerations
Again, the basic thing to keep in mind is that versioning is application-specific (although possibly, different apps may access the same file and keep a consistent versioning). At the same time, there is no problem accessing files from non-versioning apps. It is best to describe some concrete use cases. The TextEdit (TE) app saves RTF files, which can be opened and edited in any text editor; I used Sublime Text 2 (ST2) as an example.
Here's a typical, fully-versioned workflow:
- Create a file in TE
- Add some text, then 'save' or 'save a version' in TE
- Now add more text in TE, and quit without saving
- Reopen the file with TE
In this case, the window title shows 'Edited' next to the document name. Instead, consider the following:
- Create a file in TE
- Add some text, then 'save' or 'save a version' in TE
- Quit TE
- Now open ST2 and add more text, then save and quit
- Reopen the file with TE
Mac Os Download
The newly added text will show up in TE; however, the window title will not show 'Edited' next to the document name. Also, the cursor will be where it was when you quit TE. Importantly, no new versions are created. In other words, versioning must be implemented along the following lines. First, upon quitting in step 3, TE saves the state of the document under consideration: that is, it records that no editing occurred after the last explicit save. Second, the next time you run TE in Step 5, it reloads the document and the configuration file where its status is saved. The latter configuration file indicates that the user did not edit the document after explicitly saving it, so, as far as TE is concerned, the document is exactly as it was when the user quit TE in step 3, even though it is not.
Again, the way to make sense of this behavior is to think that it is the application (i.e., TE), not the OS, that provides the versioning feature. If you modify a file outside TE, clearly TE knows nothing about it: you shouldn't expect TE to keep track of such changes. On the other hand, there is one downside with this approach. Consider this sequence of events:
- Create a file in TE
- Add some text, then 'save' or 'save a version' in TE
- Add some more text in TE, so the file is now marked as 'Edited'
- Quit TE
- Now open ST2 and add more text, or delete existing text, then save and quit
- Reopen the file with TE
Upon reopening the file in TE, the document will be marked 'Edited.' However, the state of the document will of course reflect the edits done in ST2: the document state at the time you quit TE in step 4 will be lost. In the previous scenario, this was not the case, because we did an explicit save before quitting TE; thus, any change we did in ST2 could be undone by rolling back to the previously saved version. However, this option is no longer available to us in the present scenario. Again, this cannot be helped: TE knows nothing of the modifications in step 5, so when it opens the file in step 6, it just knows that some changes were made since the last save—not which changes.
The bottom line is that, if you know you will be editing a file using some non-versioning app, as well as a native, versioning app, it is a good idea to explicitly save before quitting. This is, after all, what you have been doing all along—save your documents before quitting, or sharing. The only difference is that Lion-native apps feature autosaving, and hence don't force you to save upon quitting: you have to remind yourself to do so.
