text:
Trace Adkins never has a problem telling anyone what he thinks. It's a quality that endears him to fans and gains the respect of other country artists and non-music celebrities.
A case in point is his recent win on NBC's All-Star Celebrity Apprentice, where his tenacity helped him raise more than $1.5 million for the American Red Cross. But the Louisiana native is more than a celebrity. He's an artist with formidable talent, yet he has a firm grip on reality.
In a recent interview with CMT Hot 20 Countdown producer Terry Bumgarner, he talked about his new album, Love Will. As the conversation progressed, Adkins displayed a sense of genuine gratitude for the success he's had, but he was also candid in emphasizing that he's not sure where his career is going.
As you release this album, how are you a different artist now than you were back when your first one was coming out?
Adkins: Well, let me count the ways. That's a long, long list of how I'm different now. First of all, my expectations are much different now. When I released an album back then I was livin' in a little bit of a dream world, my first album came and went platinum and I was like this is gonna be easy. And it took me a long time to hit that lick again — have one come out and go platinum or double platinum. My expectations are just not what they used to be to start with. Much more realistic now.
Nobody's expectations should be what they were before.
That's right. The world has changed — from stem to stern. I mean, it's not just the music business. It's everywhere.
On the positive side, you've built a track record. You've got a fan base and all these things that give you the confidence that you know what you're doing and that people like your work. That must take away some of the pressure so you can just focus on music.
I have a number that I pretty much know almost sell a minimum of that many units. And anything past that is gravy. And I know that I have a loyal fan base that are going to turn out and move that many units. They just like what I do, and they trust me at this point. They know that I know what they like to hear me do, and they know they're gonna get that from me. This is the first time that I've done an album that I thought had any kind of a theme to it. This one doesn't really have a theme. It's just that all the songs are love songs, you know. That, to me, fit my definition of what a love song is.
That's a pretty wide range.
Yeah, because "Badonkadonk" is a love song, so you have to keep that in mind with me right off the bat there. Just keep in mind that I classify "Badonkadonk" as a love song so … (laughs)
But it is a collection in that they've all got the same subject matter.
Really, all I'm saying with this album, where in the past I've tried to really have that roller coaster ride and have good ol' boy songs and small-town-where-I'm-from songs and maybe a political slanted song or something like that or a redneck anthem. Those kinds of things, that's not on this record. That's all I'm saying. Those songs are not on this record.
Does that kind of free you up a little bit — to not be placed in a category?
Well, what it did was, it freed me up … and I don't know what this says about where my head's been in the last year and a-half or so, but it freed me up to put my favorite songs on this disc. There was one song that I recorded — I'm not gonna tell you what it was — but there was one song that I recorded, and it broke my heart that I didn't get to put it on this record because I thought it was one of the funniest songs that I've ever recorded. And I actually considered it a love song, but it was just too goofy for everybody else. … But that's the only one that I regretted not being able to put on here. But I'll put it on something else. It's just a funny, funny song. It didn't fit on this record. But having this themed, kind of love-themed album, freed me up to put some songs on there that, to put more love songs on there than I otherwise would have and maybe to expose myself a little bit and let everybody see that I'm just a total sap, and I'm a sucker for a love song.
People look at you and go, "Oh, he's a big tough guy, and what does he know about love? What does he care about love?" Obviously, you've been thinking about it lately.
Yeah, well, you know, I've been blessed in this life to have been loved. You can love and love and love and love and love and love, but you gotta be loved, you know? And I've been fortunate that I've been loved several times.
Do you find as you get older, that these sorts of things mean more to you now than they did when you were a young guy?
Of course, now you're goin' too deep, Terry. You're goin' too deep. … Now you're starting to get into that area where a man starts to face his mortality and he starts to realize what's really important in his life and what's bullshit. (laughs)
Which is most of it.
Yeah, most everything else is all bullshit. Yeah, most of it is.
Do you feel any different than you did when you put out the last album or the one before that?
It depends on how honest she [Adkins' publicist] wants me to be here today as to why I feel about this record and what's different about it. … Well, I ain't gonna give you the happy honest version. I mean, I'm a realist. I look at this career that I've had, and it's been fantastic. It's been more than I ever could have dreamed or hoped for or wished for. And I may be getting to the end of my competitive run at radio. You what I'm sayin'? And this may be it. … If they play this one, maybe I'll stick around a little while.
I'm not trying to threaten anybody or anything like that. I'm just saying we all have our day. And when it comes to an end, you have to have the grace and the dignity to recognize, it's time — it's time to move on, maybe go do something else. I think I'm at that record, you know? I'm just layin' it out there, dude, I'm not trying to dodge or run from anything, I'm prepared for it, I'm ready for it. It doesn't terrify me. It doesn't scare me. I'll just start on another chapter.
I have a Christmas record coming out this year. … Seventeen years now, I've had a record deal. This is the first Christmas record I've ever made, and I am so proud of this Christmas record, probably more proud of this than anything that I've possibly ever done with the exception of some of those really deep, profound military songs that pay tribute to heroes. But other than that, I think, for my money, this record has more depth than anything — and it's a Christmas record. I love this record.
But just getting back to the Love Will record, yeah, we'll see. 'Cause there's no way, there is no possible way for me to set up a record better than I set this one up. Going to the finals on Celebrity Apprentice and releasing the record the week of the finale, I can't set it up any better than that. So … if they play the record, great. If they don't, I'm probably done.
But they may play it over and over and over.
And they may not play it at all.
And you know better than I do, a hit can come out of anywhere.
Yeah, I know that, and I think there's five or six hits on this record. I'm not saying that I put out some kind of inferior product. This is as good as I can possibly do. And I've got songs on this record that some people listen to and go, "Dude, that doesn't even sound like you." And I was like, "Well, I thought that song kind of asked for a pop, thinner sounding vocal, and that's the way I sang it." And I did some falsetto stuff on here, and people were like, "Whoa!" And I was like, "Man, I've been doing that for years. I just don't put it on records very often, but it's no secret that I can do that." And so, I mean, I went to the mat on this one. I didn't hold anything back. I brought my big guns to bare on this record, and we'll see what happens.


text:
[FAQ Index] [To Section 4 - Installation Guide] [To Section 6 - Networking]
,------o-----------o----X 3.9 Stable
| . .
| . ,------o---------o----X 4.0 Stable
| . | . .
| . | . ,----o----------o--> 4.1 Stable
| . | . | . .
| . | . | . ,-----o--> 4.2 Stable
| . | . | . | .
| . | . | . | .
-->3.9Rel----->4.0Rel----->4.1Rel----->4.2Rel----> Current
Time --->
-Current is where active development work is done, and eventually, it will turn into the next -release of OpenBSD. Every six months, when a new version of OpenBSD is released, -current is tagged, and becomes -release: a frozen point in the history of the source tree. Each -release is never changed; it is what is on the CDs and FTP servers.
-Stable is based on -release, and is a branch from the main development path of OpenBSD. When very important fixes are made to -current, they are "back ported" (merged) into the -stable branches; because of this, -stable is also known as the "patch branch." In the above illustration, the vertical dotted lines denote bug fixes being incorporated into the -stable branches. You will also note that in the above example, the 3.9-stable branch came to an end with 4.1-release, and the 4.0-stable branch came to an end with 4.2-release -- old releases are typically supported up to two releases back. It takes resources and time to support older versions, while we might like to provide ongoing support for old releases, we would rather focus on new features. The -stable branch is, by design, very easy to build from -release of the same version (i.e., going from 4.2-release to 4.2-stable).
The -stable branch is -release plus patches found on the errata page. The operation of -stable is the same as the -release it is based on. If the man pages have to change, it probably won't go into -stable. In other words, new device support and new features will NOT be added to -stable.
It is worth pointing out that the name "-stable" is not intended to imply that -current is unreliable. Rather, -current is changing and evolving, whereas the operation and APIs of -stable are not going to change, so you shouldn't have to relearn your system or change any configuration files, or have any problem adding additional applications to your system.
In fact, as our hope is to continually improve OpenBSD, the goal is that -current should be more reliable, more secure, and of course, have greater features than -stable. Put bluntly, the "best" version of OpenBSD is -current.
Warning: -current is a moving target. It changes minute by minute, and may well change several times in the time it takes to retrieve the source code. While the developers work hard to ensure that the system always compiles and that there are no major bugs, it is entirely possible to get the -current source and have it fail to compile, whereas five minutes later everything will be just fine. There are also flag days and major system changes that the developers navigate with one-time tools, which mean that source-based updating is not possible. If you are not prepared to deal with this, stay away from -current.
Most users should be running either -stable or -release. That being said, many people do run -current on production systems, and it is important that some people do so to identify bugs and test new features. However, if you don't know how to properly describe, diagnose and deal with a problem, don't tell yourself (or anyone else) that you are "helping the project" by running -current. "It didn't work!" is not a useful bug report. "The recent changes to the pciide driver broke compatibility with my Slugchip-based IDE interface, dmesg of working and broken systems follow..." might be a useful report.
There are times when "normal" users may wish to live on the cutting edge and run -current. The most common reason is that the user has a device which is not supported by -release (and thus, not -stable), or wishes to use a new feature of the -current. In this case, the choice may be either -current or not using the device, and -current may be the lesser evil. However, one should not expect hand-holding from the developers.
It is sometimes asked if there is any way to get a copy of exactly the code used to build a snapshot. The answer is no. First, there is no significant benefit to this. Second, the snapshots are built as desired, as time permits, and as resources become available. On fast platforms, several snapshots may be released in one day. On slower platforms, it may take a week or more to build a snapshot. Providing tags or markers in the source tree for each snapshot would be quite impractical. Third, snapshots often contain experimental code that isn't yet committed to the tree.
Upgrading is the process of installing a newer version of
OpenBSD, with new functionality.
For example, going from v4.1 to v4.2, or going from the June 12th
snapshot to the June 20th snapshot.
When upgrading, you will typically have to consult either
Following -current or the
Upgrade guide (when changing releases)
to make the changes required to run the upgraded version of OpenBSD.
Updating is the process of applying patches to a system to improve the operation WITHOUT changing the basic functionality or binary compatibility. This is typically done by following the source patching process or by following the stable process. When you "update" your system, it goes from a -release to a -stable (or patched -release) of the same release version, for example, 4.2-release to 4.2-stable. You may then later update it to a newer -stable of the same release version. The update process is typically very painless, as no /etc files or other system configurations need to be changed.
So, you may install a system (for example, 4.1-release) from CD, then update it to 4.1-stable a few times, then upgrade it to 4.2-release from CD, and update that a few times before upgrading it again to the next release.
One should also understand that the upgrade process is supported in only one direction: from older to newer, and from -stable to -current. You can not run 4.2-current (or a snapshot), then decide you are living too dangerously, and step back to 4.2-stable. You are on your own if you choose any path other than the supported option of reloading your system from scratch, do not expect assistance from the OpenBSD development team.
Yes, this does mean you should think long and hard before committing yourself to using -current.
Some reasons why NOT to build from source:
The OpenBSD team puts out new snapshots based on -current code on a very regular basis for all platforms. It is likely this will be all you need for running -current.
The most common reason to build from source is to follow the -stable branch, where building from source is the only supported option.
|You are at
|Binary upgrade to
|then ...
|Old -release
|New release
|Newest release
|Newest release
|Fetch & build -stable
|Old -stable
|Newest release
|Fetch & build -stable
|Latest Snapshot
|(optional) Fetch & build -current
|Old -current
|Latest Snapshot
|(optional) Fetch & build -current
It is recommended that you install the binary by using the "Upgrade" option of the install media. If that is not possible, you can also unpack the binaries as described here. Regardless, you must do the entire upgrade process, including creating any users or other /etc directory changes needed.
After deciding which AnonCVS server you wish to use, you must "checkout" the source tree, after that, you then maintain the tree by running "updates", to pull updated files to your local tree.
The CVS(1) command has many options, some of them are required to checkout and update a useful tree. Other commands can cause a broken tree. Following and understanding directions here is important.
Following -current
In this case, we will assume we are using a public AnonCVS server, firstname.lastname@example.com:/cvs. We will also assume you are using sh(1) as your command shell, if you are using a different shell, you will have to adjust some of these commands.Following -Stable
To checkout a -current CVS src tree, you can use the following:
# cd /usr # export firstname.lastname@example.com:/cvs # cvs -d$CVSROOT checkout -P src
Once you have a tree, you can update it at a later time:
# cd /usr/src # export email@example.com:/cvs # cvs -d$CVSROOT up -Pd
If you wish to check out an alternative "branch" of the tree, such as the -stable branch, you will use the "-r" modifier to your checkout:
# cd /usr # export email@example.com:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P srcThis will pull the src files from the OPENBSD_4_2 branch, which is also known as the "Patch branch" or "-stable". You would update the code similarly:
# cd /usr/src # export firstname.lastname@example.com:/cvs # cvs -d$CVSROOT up -rOPENBSD_4_2 -PdActually, CVS is nice enough to stick a "Tag" in the checked out file system, so you don't have to remember the "-rOPENBSD_4_2" part of the command line, it will remember this until you explicitly clear them or set a new tag by using the "-A" option to "update". However, it is probably better to provide too much info in your CVS command lines than too little.
While only the "src" tree has been shown so far, you will do the
same steps for "xenocara" and "ports".
As all parts of OpenBSD must be kept in sync, all trees you use should be
checked out and updated at the same time.
You can combine the checkouts into one line (-stable shown):
# export firstname.lastname@example.com:/cvs
# cd /usr
# cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src ports
# cd /usr/src
# cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P xenocara
However, updates must be done directory-by-directory.
At this point, whether you followed -stable or -current you should have a usable source tree. Be very careful which tree you grab -- it is easy to try to compile -current when aiming for -stable.
To extract the source tree from the CD to /usr/src (assuming the CD is
mounted on /mnt):
# cd /usr/src; tar xzf /mnt/src.tar.gz
# tar xzf /mnt/xenocara.tar.gz
# cd /usr; tar xzf /mnt/ports.tar.gz
The source files available for download from the FTP servers are separated into two
files to minimize the download time for those wishing to work
with only one part of the tree. The two files are sys.tar.gz,
which contains the files used to create the kernel, and src.tar.gz
which contains all the other "userland" utilities except the ports tree
and the X11 sources.
In general, however, you will usually want both of them installed.
Assuming the downloaded files, src.tar.gz and
sys.tar.gz, are in /usr:
# cd /usr/src
# tar xzf ../sys.tar.gz
# tar xzf ../src.tar.gz
# tar xzf ../xenocara.tar.gz
# cd /usr
# tar xzf ports.tar.gz
Not all people will wish to unpack all the file sets, but as the system must be kept in sync, you will generally need to set up all parts of the tree.
Much the same with the -d option on the 'update' command -- it creates new directories that may have been added to the tree since your initial checkout. To get a successful update, you must use the -Pd options.
Experienced CVS users may wonder why the CVSROOT was specified and used in this example, as cvs(1) will record the CVS server's location in the checked out tree. This is correct, however there are enough times where one may need to override the default anoncvs server, many people recommend always specifying the repository explicitly. It is also worth noting that while the CVSROOT environment variable can be used directly by cvs(1), it is used only if nothing else overrides it (i.e., cvs(1) would have an error without it), whereas specifying it in the cvs(1) command line overrides all other values.
It is often useful to use a .cvsrc in your home directory to
specify defaults for some of these options.
An example .cvsrc file:
$ more ~/.cvsrc
cvs -q -firstname.lastname@example.com:/cvs
diff -up
update -Pd
checkout -P
This file would cause cvs(1) to use the
email@example.com:/cvs server, suppress usually
unneeded output ("-q" is "quiet") for all operations,
a "cvs up" command defaults to using the -Pd,
a "cvs diff" defaults to providing "unified diffs" due to the "-u",
and a "cvs checkout" will use the "-P" option.
While this is convenient, if you forget this file exists, or try to run
commands you got used to on a machine without this file, you will have
As the source trees consist of large numbers of mostly small files, turning on soft updates for the partition the source tree is on will often give significantly better performance.
Obviously, the kernel is a VERY hardware dependent portion of the system. The source for the kernel is in the /usr/src/sys directory. Some parts of the OpenBSD kernel code are used on all platforms, others are very specific to one processor or one architecture. If you look in the /usr/src/sys/arch/ directory, you may see some things that look a little confusing -- for example, there are mac68k, m68k and mvme68k directories. In this case, the mvme68k and mac68k systems both use the same processor, but the machines they are based on are very different, and thus require a very different kernel (there is much more to a computer's design than its processor!). However, parts of the kernel are common, those parts are kept in the m68k directory. If you are simply building a kernel, the base architecture directories like m68k are not anything for you to worry about, you will be working exclusively with the "compound architecture" directories, such as mvme68k.
Kernels are built based on kernel configuration files, which are located in the /usr/src/sys/arch/<your platform>/conf directory. Building the kernel consists of using the config(8) program to create and populate a kernel compile directory, which will end up in /usr/src/sys/arch/<your platform>/compile/<KernelName>. For this example, we will assume you are using the i386 platform:
Replace "i386" in the first line with your platform name.
command can tell you what your platform name is, so an obvious
generalization would be to use the command "cd
/usr/src/sys/arch/`machine`/conf" instead on the first line.
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make depend && make
[...lots of output...]
# make install
At this point, reboot your machine to activate this new kernel. Note that the new kernel should be running before the next step, though if you have followed the above advice about upgrading to the most recent available snapshot, it may not matter as much. Sometimes, however, APIs change, and the old kernel will be unable to run new applications, but the new kernel will generally support the old ones.
Note that you can build a kernel without root access, but you must have
root to install the kernel.
$ cd /somewhere
$ cp /usr/src/sys/arch/i386/conf/GENERIC .
$ config -s /usr/src/sys -b . GENERIC
$ make clean && make depend && make
... lots of output ...
Note that the use of the /usr/obj directory is mandatory.
Failing to do this step before building the rest of the tree will likely
leave your src tree in bad shape.
# rm -rf /usr/obj/*
# cd /usr/src
# make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
This compiles and installs all the "userland" utilities in the
appropriate order.
This is a fairly time consuming step -- a very fast machine may be able
to complete it in well under an hour, a very slow machine may take many
When this step is complete, you have newly compiled binaries in place
on your system.
# cd /usr/src
# make build
The release process uses the binaries created in the /usr/obj directory in the building process above, so you must successfully complete the build first, and nothing must disturb the /usr/obj directory. A time where this might be a problem is if you use a memory disk as your /usr/obj for a little extra performance in the build process, you would not want to reboot the computer between the "build" and "release" steps!
The release process requires two work directories, which we will call DESTDIR and RELEASEDIR. All the files that are part of a "clean" OpenBSD install will be copied to their proper place within the DESTDIR. They will then be tar(1)ed up and placed in the RELEASEDIR. At the end of the process, RELEASEDIR will hold the completed OpenBSD release. The release process will also use the /mnt location, so this should not be used by anything while the release process is running. For the purpose of example, we will use the DESTDIR of /usr/dest and the RELEASEDIR of /usr/rel.
The release process involves a couple utilities which are not in the base OpenBSD system, crunch and crunchgen(1), which are used to create a single executable file made up of many individual binaries. The name this single executable file is invoked by determines which component binary is run. This is how a number of individual program files are squeezed into the ramdisk kernel that exists on boot floppies and other boot media. These utilities must be built before the release process is started. They only need to be built and installed once, but as people often forget this step, and these programs build quickly, some people opt to just build crunch and crunchgen every time as part of the script they use to make a release.
You must have root privileges to make a release.
Now, we define our DESTDIR and RELEASEDIR environment variables:
# cd /usr/src/distrib/crunch && make obj depend all install
We now clear the DESTDIR and create the directories if needed:
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
RELEASEDIR does not normally need to be empty before starting the release
process, however, if there are changes in the release files or their names,
old files may be left laying around.
You may wish to also erase this directory before starting.
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
We now make the release itself:
After the release is made, it is a good idea to check the release to
make sure the tar files are matching what is in the DESTDIR.
The output of this step should be very minimal.
# cd /usr/src/etc
# make release
You now have complete and checked release file sets in the RELEASEDIR.
These files can now be used to install or upgrade OpenBSD on other
# cd /usr/src/distrib/sets
# sh checkflist
The authoritative instructions on making a release are in release(8).
Note: if you wish to distribute the resultant files by HTTP for use by the upgrade or install scripts, you will need to add an "index.txt" file, which contains the list of all the files in your newly created release.
# /bin/ls -1 >index.txt
Starting with X.org v7, X switched to "modular build" system, splitting the x.org source tree into more than three hundred more-or-less independent packages.
To simplify life for OpenBSD users, a "meta-build" called Xenocara was developed. This system "converts" X back into one big tree to be built in one process. As an added bonus, this build process is much more similar to the build process used by the rest of OpenBSD than the previous versions were.
The official instructions for building X exist in your machine's /usr/src/xenocara/README file and in release(8).
$ cd /usr/src
$ cvs -firstname.lastname@example.com:/cvs checkout -P xenocara
If you wish to make actual modifications to the source code, you will
probably need to add several packages.
Details are in the /usr/src/xenocara/README file.
# cd /usr/src/xenocara
# make bootstrap
# make obj
# make build
For this example, we will use a DESTDIR and RELEASEDIR of /usr/dest and /usr/rel, respectively. This must be done after the above build process.
When this process is completed, you will have a set of release files
in the $RELEASEDIR.
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
rm -rf ${DESTDIR}- &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
# make release
Actually, you probably don't.
A custom kernel is a kernel built with a configuration file other than the provided GENERIC configuration file. A custom kernel can be based on -release, -stable or -current code, just as a GENERIC kernel can be. While compiling your own GENERIC kernel is supported by the OpenBSD team, compiling your own custom kernel is not.
The standard OpenBSD kernel configuration (GENERIC) is designed to be suitable for most people. More people have broken their system by trying to tweak their kernel than have improved system operation. There are some people that believe that you must customize your kernel and system for optimum performance, but this is not true for OpenBSD. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system.
Some reasons you might want or need to build a custom kernel:
Some reasons why you should not build a custom kernel:
Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. Removing device drivers will not make your system run faster by any noticeable amount, though can produce a smaller kernel. Removing debugging and error checking can result in a measurable performance gain, but will make it impossible to troubleshoot a system if something goes wrong.
Again, developers will usually ignore bug reports dealing with custom kernels, unless the problem can be reproduced in a GENERIC kernel as well. You have been warned.
OpenBSD kernel generation is controlled by configuration files, which are located in the /usr/src/sys/arch/<arch>/conf/ directory by default. All architectures have a file, GENERIC, which is used to generate the standard OpenBSD kernel for that platform. There may also be other configuration files which are used to create kernels with different focuses, for example, for minimal RAM, diskless workstations, etc.
The configuration file is processed by config(8), which creates and populates a compilation directory in ../compile, on a typical installation, that would be in /usr/src/sys/arch/<arch>/compile/. config(8) also creates a Makefile, and other files required to successfully build the kernel.
Kernel Configuration Options are options that you add to your kernel configuration that place certain features into your kernel. This allows you to have exactly the support you want, without having support for unneeded devices. There are a multitude of options that allow you to customize your kernel. Here we will go over only some of them, those that are most commonly used. Check the options(4) man page for a complete list of options, and as these change from time to time, you should make sure you use a man page for the same version of OpenBSD you are building. You can also check the example configuration files that are available for your architecture.
Do not add, remove, or change options in your kernel unless you actually have a reason to do so! Do not edit the GENERIC configuration file!! The only kernel configuration which is supported by the OpenBSD team is the GENERIC kernel, the combination of the options in /usr/src/sys/arch/<arch>/conf/GENERIC and /usr/src/sys/conf/GENERIC as shipped by the OpenBSD team (i.e., NOT edited). Reporting a problem on a customized kernel will almost always result in you being told to try to reproduce the problem with a GENERIC kernel. Not all options are compatible with each other, and many options are required for the system to work. There is no guarantee that just because you manage to get a custom kernel compiled that it will actually run. There is no guarantee that a kernel that can be "config(8)ed" can be built.
You can see the platform-specific configuration files here:
Look closely at these files and you will notice a line near the top
similar to:
include "../../../conf/GENERIC"
This means that it is referencing another configuration file, one
that stores platform-independent options. When creating your kernel
configuration, be sure to look through
Kernel configuration options should be placed in your kernel configuration file in the format of:
option nameor
For example, to place option "DEBUG" in the kernel, add a line like this:
option name=value
Options in the OpenBSD kernel are translated into compiler preprocessor
options, therefore an option like DEBUG would have the source compiled
with option -DDEBUG, which is equivalent to doing a #define DEBUG
throughout the kernel.
option DEBUG
Sometimes, you may wish to disable an option that is already defined,
typically in the "src/sys/conf/GENERIC" file. While you could
modify a copy of that file, a better choice would be to use the
rmoption statement. For example, if you really wanted to
disable the in-kernel debugger (not recommended!), you would add
a line such as:
rmoption DDB
in your kernel configuration file. option DDB is defined in
src/sys/conf/GENERIC, but the above rmoption line
deactivates it.
Once again, please see options(4) for more information about the specifics of these options. Also note that many of the options also have their own manual pages -- always read everything available about an option before adding or removing it from your kernel.
The two lines regarding the boca(4) card are copied from the commented
out lines in GENERIC, with the IRQ adjusted as needed.
The advantage to using this "wrapper" file is any unrelated changes in
GENERIC are updated automatically with any other source code update.
The disadvantage is one can not remove devices (though in general, that's
a bad idea, anyway).
include "arch/i386/conf/GENERIC"
boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards
pccom* at boca? slave ?
Another way to generate a custom kernel is to make a copy of the standard GENERIC, giving it another name, then editing it as needed. The disadvantage to this is later updates to the GENERIC configuration file have to be merged into your copy, or you have to remake your configuration file.
In either event, after making your custom kernel configuration file, use config(8) and make the kernel as documented above.
Full instructions for creating your own custom kernel are in the afterboot(8) man page.
Sometimes when booting your system you might notice that the kernel finds your device but maybe at the wrong IRQ. And maybe you need to use this device right away. Well, without rebuilding the kernel you can use OpenBSD's boot time kernel configuration. This will only correct your problem for one time. If you reboot, you will have to repeat this procedure. So, this is only meant as a temporary fix, and you should correct the problem using config(8). Your kernel does however need option BOOT_CONFIG in the kernel, which GENERIC does have.
Most of this document can be found in the man page boot_config(8).
To boot into the User Kernel Config, or UKC, use the -c option at boot time.
Or whichever kernel it is you want to boot. Doing this will bring up a
UKC prompt. From here you can issue commands directly to the kernel
specifying devices you want to change or disable or even enable.
boot> boot hd0a:/bsd -c
Here is a list of common commands in the UKC.
Once you have your kernel configured, use quit or exit and continue booting. After doing so, you should make the change permanent in your kernel image, as described in Using config(8) to change your kernel.
The -e and -u options with config(8) can be extremely helpful and save wasted time compiling your kernel. The -e flag allows you to enter the UKC or User Kernel Config on a running system. These changes will then take place on your next reboot. The -u flag tests to see if any changes were made to the running kernel during boot, meaning you used boot -c to enter the UKC while booting your system.
The following example shows the disabling of the ep* devices in the kernel. For safety's sake you must use the -o option which writes the changes out to the file specified. For example : config -e -o bsd.new /bsd will write the changes to bsd.new. The example doesn't use the -o option, therefore changes are just ignored, and not written back to the kernel binary. For more information pertaining to error and warning messages read the config(8) man page.
$ sudo config -e /bsd
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
nmbclust [number] Show/change NMBCLUSTERS
cachepct [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
shmseg [number] Show/change SHMSEG
shmmaxpgs [number] Show/change SHMMAXPGS
ukc> list
0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*
|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|
*|ep*|ep* phy -1 flags 0x0
4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
p*|ep* phy -1 flags 0x0
ukc> disable ep
67 ep0 disabled
68 ep* disabled
69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced
In the above example, all ep* devices are disabled in the kernel and will not be probed. In some situations where you have used the UKC during boot, via boot -c, you will need these changes to be written out permanently. To do this you need to use the -u option. In the following example, the computer was booted into the UKC and the wi(4) device was disabled. Since changes made with boot -c are NOT permanent, these changes must be written out. This example writes the changes made from boot -c into a new kernel binary bsd.new.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit
UKC> verbose
autoconf verbose enabled
UKC> quit
Now you will be given extremely verbose output upon boot.
Most problems are usually one of the following:
Building OpenBSD and other programs from source is a task which pushes hardware harder than most others, making intensive use of CPU, disk and memory. As a result, if you have hardware which has a problem, the most likely time for that problem to appear is during a build. Signal 11 failures are typically caused by hardware problems, very often memory problems, but can also be CPU, main board, or heat issues. Your system may actually be very stable otherwise, but unable to compile programs.
You will probably find it best to repair or replace the components that are causing trouble, as problems may show themselves in other ways in the future. If you have hardware which you really wish to use and causes you no other problem, simply install a snapshot or a release.
For much more information, see the Sig11 FAQ.
# cd /usr/src
# find . -type l -name obj | xargs rm
# make cleandir
# rm -rf /usr/obj/*
# make obj
# umount /usr/obj
# newfs YourObjPartition
# mount /usr/obj
than to "rm -rf /usr/obj/*".
Note: it is possible to make a broken system this way. The results of this option are not supported by the OpenBSD project.
Snapshots may be removed as they become old (or no longer relevant) or near the time of a new -release.
OpenBSD now supports two compilers in-tree, gcc v3.3.5 used by most platforms, but also gcc v2.95.3 used by a few platforms which haven't been converted yet, or may never be converted due to lack of gcc3 support or poor gcc3 performance.
The two compilers are in different parts of the tree:
Because upgrading a compiler is a bit of a chicken-and-egg problem,
changes to the in-tree compiler require a little extra attention.
You have to build the compiler twice -- the first build produces a
compiler that generates new code but runs with code generated by the old
compiler, the second build makes it a completely new compiler.
In general, you'll want to perform the following procedure:
If your platform uses gcc 2.95.3:
# rm -r /usr/obj/gnu/egcs/gcc/*
# cd /usr/src/gnu/egcs/gcc
- or -
If your platform uses gcc 3.3.5:
# rm -r /usr/obj/gnu/usr.bin/gcc/*
# cd /usr/src/gnu/usr.bin/gcc
Common build procedure for v3.3.5 or v2.95.3
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
And then run a normal make build.
As a policy, software in the OpenBSD tree does not modify files in /etc automatically. This means it is always up to the administrator to make the necessary modifications there. Upgrades are no exception. To update files in these directories, first determine what changes have occurred to the base (distribution) files, and then manually reapply these changes.
For example, to see the files in the tree that have changed most
recently, do a:
# cd /usr/src/etc
# ls -lt |more
To see all the changes in /etc between arbitrary versions of
OpenBSD, you can use CVS.
For example, to see the changes between 4.1 and 4.2 do a:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_4_1 -rOPENBSD_4_2
To see the changes between 4.2 and -current ("HEAD"), use:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_4_2 -rHEAD
script is not updated automatically as part of the make build process,
however it is installed as as part of a binary
As a general rule, it is a good idea to copy (if needed) and run this
script from your source tree when performing an upgrade:
# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all
Once you have identified the changes, reapply them to your local tree, preserving any local configuration you may have done.
Typical /etc changes to watch out for between releases include:
From time to time, files or directories are added to, or removed from the file hierarchy. Also, ownership information for portions of the filesystem may change. An easy way to ensure that your file hierarchy is up-to-date is to use the mtree(8) utility.
First, fetch the latest source, then do the following:
# cd /usr/src/etc/mtree
# install -c -o root -g wheel -m 600 special /etc/mtree
# install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
# mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Your file hierarchy should now be up to date.
When the developers bring up support for a new platform, one of the first big tests is a native-build. Building the system from source puts considerable load on the OS and machine, and does a very good job of testing how well the system really works. For this reason, OpenBSD does all the build process on the platform the build is being used for, also known as "native building". Without native building, it is much more difficult to be sure that the various platforms are actually running reliably, and not just booting.
[FAQ Index] [To Section 4 - Installation Guide] [To Section 6 - Networking]

subset: commoncrawl


text:
The Central Connecticut men's cross country team finished 11th out of 37 teams at the New England Cross Country Championships in Westfield, MA Sunday. Junior Colby Delbene finished first for the Blue Devils, coming in 13th place out of 261 runners with a time of 24:45.21. Delbene finished just under a minute behind first place winner, Mike Biwott, from American International.
Crossing the finish line second for Central was junior Andrew Hill, who placed 53rd overall with a time of 25:25.28. Just nine seconds later, Hill was followed by sophomore Brian Biekert in 64th. Rounding out the scoring for the Blue Devils was freshman David Scheibenpflug (126th) with a time of 26:08.63 followed closely by sophomore Patrick Hubbell (128th) who crossed the line in 26:09.06.
Freshman Tyler Raymond (142nd) and redshirt-freshman Matt Walker (178th) also participated in the race for CCSU.
Dartmouth earned the New England Cross Country Champion title, coming in first place overall, followed by Boston College, Yale, Boston University, Tufts, Bowdoin, American International, Williams, Northeastern and the University of Connecticut. Central finished just 20 points behind UCONN and was followed by Bentley, MIT, Stonehill, Southern Connecticut, Fairfield, Springfield, Sacred Heart, UMASS Amhurst, New Hampshire, Holy Cross, Maine, Quinnipiac, Vermont, Keene State, Hartford, Lyndon State, UMASS Lowell, Brandeis, Rhode Island, Bryant, Merrimack, Franklin Pierce, New Haven, Eastern Connecticut, St. Michael's and UMASS Boston.
Central placed highest among the Northeast Conference teams competing in the race and will return to action on Friday, Oct. 19 at the CCSU Mini Meet. The men's race is set to begin at 4 p.m. at Stanley Quarter Park in New Britain, CT.


text:
Oppressed Peoples Online Word...The Voice Of The Voiceless
Dedicated to disseminating news & information not found in mainstream media....
Kabul (CNN) -- The ordeal of Gulnaz did not simply begin and end with the physical attack of her rape. The rape began
By Nick Paton Walsh and Masoud Popalza, CNN
a years-long nightmare of further pain, culminating in an awful choice she must now make.
Even two years later, Gulnaz remembers the smell and state of her rapist's clothes when he came into the house when her mother left for a brief visit to the hospital.
"He had filthy clothes on as he does metal and construction work. When my mother went out, he came into my house and he closed doors and windows. I started screaming, but he shut me up by putting his hands on my mouth," she said.
The rapist was her cousin's husband.
After the attack, she hid what happened as long as she could. But soon she began vomiting in the mornings and showing signs of pregnancy. It was her attacker's child.
In Afghanistan, this brought her not sympathy, but prosecution. Aged just 19, she was found guilty by the courts of sex outside of marriage -- adultery -- and sentenced to twelve years in jail.
Now inside Kabul's Badam Bagh jail, she and her child are serving her sentence together.
Sitting with the baby in her lap, her face carefully covered, she explains the only choice she has that would end her incarceration.
The only way around the dishonor of rape, or adultery in the eyes of Afghans, is to marry her attacker. This will, in the eyes of some, give her child a family and restore her honor.
Incredibly, this is something that Gulnaz is willing to do.
"I was asked if I wanted to start a new life by getting released, by marrying this man", she told CNN in an exclusive interview. "My answer was that one man dishonored me, and I want to stay with that man."
Tending to her daughter in the jail's cold, she added: "My daughter is a little innocent child. Who knew I would have a child in this way. A lot of people told me that after your daughter's born give it to someone else, but my aunt told me to keep her as proof of my innocence."
Gulnaz's choice is stark. Women in her situation are often killed for the shame their ordeal has brought the community. She is at risk, some say, from her attacker's family.
We found Gulnaz's convicted rapist in a jail across town. While he denied raping her, he agreed that she would likely be killed if she gets out of jail. But he insists that it will be her family, not his, that will kill her, "out of shame."
Whether threatened by his family or hers, for now, jail may be the safest place for her.
Shockingly, Gulnaz's case is common in Afghanistan.
CNN asked a spokesman for the prosecutor to comment on the case. The reply was that there were hundreds such cases and the office would need time to look into it.
But Gulnaz's plight has found international attention because of a dispute between the European Union and a team of documentary makers hired to report on women's rights in Afghanistan.
The documentary makers filmed a lengthy report on Gulnaz and other women, showing her talking openly about her fate. They showed the film to the EU, who were paying for it as part of a project on female rights here. After viewing it, the EU decided to spike the project.
The EU said it was concerned about the safety of the women in the film: they could be identified and might face reprisals. The filmmakers however suspect -- citing an email leaked from the EU delegation -- that the EU might also be motivated by its sensitive relationship with Afghan justice institutions, since he film shows the Afghan justice system in a very unflattering light.
The leaked email says: "The delegation also has to consider its relations with [Afghan] Justice institutions in connection with the other work that it is doing in the sector."
The EU Ambassador to Afghanistan, Vygaudas Usackas, rejected any political motivation in asking for the film not to be shown.
"What I am concerned about is that situation of the women. About the security and well being, that's of paramount importance, the key criteria according to which I, as representative of the European Union will judge," said the ambassdor.
Under Afghan law, Gulnaz has been judged an adulterer. Despite the ongoing dispute over her story, her predicament has not changed. She faces the hideous choice of 12 years in jail or marriage to her rapist and risk death. It's a marriage she says she'll accept, so her child can continue to have a mother.
Crisis In The Horn Of Africa Pictures 1432 AH
If you like this article please consider donating to : Oppressed Peoples Online Word
Mission Statement Of Oppressed Peoples Online Word
Oppressed Peoples Online Word Facebook
O.P.O.W. Email: email@example.com
Recent Stories On Oppressed Peoples Online Word
World News Up-dated : Mosaic World News
Views: 66
Join Oppressed Peoples Online Word...The Voice Of The Voiceless
© 2020 Created by Bilal Mahmud المكافح المخلص. Powered by


text:
Many places in the U.S. are not gluten-free friendly and many places are great to visit if you're gluten-free. New York City and Atlanta are fantastic in terms of gluten-free shopping and dining, while Panama City Beach, FL is horrid. For this reason, many people who can't eat gluten pack an extra suitcase full of food for any trip.
Taking your own food on trips is often a good idea. It is a terrible feeling to find yourself without something safe to eat – even if it's just a cracker to nosh on when others around you are dining on gluten filled appetizers. It's a good idea to keep a survival pack of food in your car, even if you're not leaving town. There is something comforting about knowing there is safe food available, should a need for it arise.
If you are traveling from the U.S. to some parts of Europe, you might want to rethink your packing habits. Planning our first visit overseas after my celiac diagnosis was scary. Through much research I knew that it seemed easier to eat out outside the U.S. than at home, but until you experience that for yourself you're a skeptic.
We have a packing rule at our house. Whatever bags you pack, you have to be able to carry. Still, I packed one extra back pack full of food including, but not limited to ; pretzels, dried fruit, nuts, nutrition bars, crackers, salad dressings, honey packets, soy sauce packets, etc. We ate several bars and some nuts and fruit during our trip, and I ate crackers almost every morning with cheeses served at our hotels. Some days I needed the crackers with lunch and other days I did not.
In the end, we came home with a back pack 90% full of food. You need to find out if your destination is gluten-free friendly or not, before deciding how much food to pack. For instance, London, Paris and many parts of Italy are very gluten-free friendly in terms of buying food. Though celiac diagnosis rates are almost nil in Greece, the larger areas have gluten-free food for visitors. You can stock up on shelf stable foods before beginning your island hopping. The Greek diet is not overloaded with gluten and hence they have very little incidence of celiac there.
Gluten-free food is sold in the pharmacias in Italy. In Paris the health food stores carry shelf stable brands like Valpi-Form. In London the Tesco and Sainsbury's stores have excellent selections. Those stores have shelf stable gluten-free food lines which are sort of like gourmet Hostess products. We stocked up on tiny cakes from Sainbury's to use in Paris for breakfast. Valpi-Form in France makes scrumptious Madeleines which you'll find hard to believe are gluten-free.
The only problem with visiting some of these places is that you'll likely want to move there when you find out how easy it is to eat out there compared to here. We returned from our trip and I started researching how we could move to Europe. Then I decided instead of running from the challenge of navigating the gluten-free lifestyle here, I should do everything possible to change things on my own turf. Three years later that work continues.
For more info: Visit Gluten-Free Passport and Special Gourmets for gluten-free friendly places in many countries.
Author Information: Tiffany Janes, Atlanta, GA
website : www.glutenfreepromotions.com
e-mail : email@example.com


text:
Grundpreis.: 6,99 €/100g
Summerbird - GUAYAS - Almonds 100g
This light roastet spanish almond, panned with a thin layer of nougat, strong organic Peru 71% dark chocolate, sea salt and roasted crushed cocoa beans have lots of character, depth and edge.
The chocolate dandruff's crisp, light bitter and deep flavor leaves an impression of nature and love for chocolate.
*Almonds (28%), *cocoa mass, *cane sugar, *hazelnuts, *cocoabutter, *crushed cocoa beans (3%),
emulsifier (*soya lecithin), vanilla extract, sea salt.
May contain traces of tree nuts and their by-products, sesame, eggs, milk and gluten/Kann spuren von Schalenfrüchten, Sesam, Ei, Milch und Gluten enthalten/Kan indeholde spor af nødder, sesam, æg, mælk og gluten.
Nutrition information (typical values per 100g)
|Energie / Energy
|2511kJ / 600 kcal
|Fett / Fat
|- davon gesättigte Fettsäuren / - of which saturates
|Kohlenhydrate /Carbohydrat
|- davon Zucker / - of which sugars
|Ballaststoffe / Fibre
|Eiweiß / Protein
|Salz / Salt
Art.-Nr. / Item Number: 4651
Summerbird Bio Controll Number
DK-ÖKO-100 - EU Landwirtschaft
Summerbird A/S
Mandel Alléen 6, 5610 Assens Danmark
Ust-Idnr. 2420 9644
Chokodays is certified to sell organic foods by ABCERT AG, Martinstr. 42-44, D 73728 Esslingen, (DE-ÖKO-006). Our certificate is available from our control body under the certificate reference [DE-SH-006-25262-H].
* All prices in Euro incl. VAT. : VAT. incl. in Shipping costs for the entire cart.
** Chocolate products on this site may contain traces of milk, egg, and traces of nuts/peanuts. Unless specified in the product description.
Product information and Website Disclaimers:We at chokodays strive on our (chokodays) websites to ensure the accuracy of our product information, it can sometimes happen that manufacturers change their ingredients. The product images, packaging and related documentation may contain information beyond the information given on our (chokodays) websites. All product information on our website are provided for information purposes only. We recommend that you do not to rely solely on the information that appears on our (chokodays) website, but always carefully review and read the labels, warnings and instructions before use or consumption of any our products being sold on (chokodays) websites. If you have concerns of any kind or want more information about the products, please carefully read the information on the labels and packaging and contact the manufacturers of the product. Contact information for the manufacturers can be found at the bottom of all product pages. The information on this site cannot replace information provided by your physician, pharmacist or any other health professional. Please contact your doctor or pharmacist for questions regarding the compatibility of risks or side effects when taking or using the products in question. The product descriptions and other information about the products are not intended to diagnose, treat, cure or prevent any disease or health condition. Chokodays.de or (chokodays) websites is not liable for any incorrect or inaccurate product information from manufacturers or information provided by other third parties. Your statutory rights remain unaffected.
Tip: Note on Possible Color DeviationsAll color information without guarantee - deviations are possible Please note that it may occur, especially using different display technologies and the settings of your individual display that distortions to the colors may occur. The colors displayed on your screen may be slightly different from the actual color of the products shown in our product photos. Please contact us for any questions regarding the images of our products and/or the colors of the products being purchased.
Du hast Fragen zu unseren Versandoptionen? Die häufigsten Fragen und Antworten findest du auf dieser Seite.


text:
Watch "Dance On That Work" by Cap 1
Cap 1's lastest EP Bird Bath dropped last week and today he releases a video for "Dance On That Work" which appears on the project.
Directed by Zae.
Street Exec's DJ E Sudd liberates a new track from Cap 1 about a "Side Piece".
Cap 1 – Momma (Official Music Video)
Celebrating with his "Momma" Cap 1 premieres a new video for his Mother's Day friendly single.
Cap 1 – Blessings (Feat. Big K.R.I.T.) (Official Music Video)
Cap 1 is joined by Big K.R.I.T. in the video for their collaboration titled "Blessings". The record appears on the recently released mixtape TruPac….
Cap 1 – Tonite (Feat. 2 Chainz, Jeremih & Verse Simmonds)
Gearing up to release his Trupac project, Cap 1 drops off a new single "Tonite" featuring 2 Chainz, Jeremih and Verse Simmonds. Source: HolidaySeasonLive
Cap 1 and 2 Chainz collaborate over head rocking TM88 production on a new track titled "#Nawswear."
Cap 1 – 1000 Pints (Official Music Video)
In support of his Bird Bath EP, Cap 1 drops off a new visual for his lean-consuming anthem "1000 Pints."
Project Pat – Them O's (Feat. Young Dolph & Cap 1) (Official Music Video)
In support of his Mistah Don't Play 2: Everythangs Money album, Project Pat drops off a visual for "Them O's" featuring Young Dolph and…
DJ Spinatik – Came From Nothin (Mixtape)
DJ Spinatik liberates his new mixtape Came From Nothin. The project features new music by Bankroll Fresh, Cap 1, Kevin Gates, Gunplay, Killa Kyleon,…
2 Chainz – Trap House Stalkin (Feat. Young Dolph & Cap 1) (Official Music Video)
2 Chainz, Young Dolph and Cap 1 head back to the trap house in the visual for their T.R.U. Jack City mixtape cut.
Cap 1 & Verse Simmonds – M.O.B. (Official Music Video)
Cap 1 and Verse Simmonds connect and drop a visual for this Metro Boomin produced track "M.O.B."
2 Chainz – Keep It 100 (Feat. Short Dawg, Cap 1, Skooly & Kaelub) (Official Music Video)
In support of the TRU Jack City mixtape, 2 Chainz, Short Dawg, Cap 1, Skooly, and Kaelub come together for a new visual dedicated…
Young Buck – Gas Up (Feat. Cap 1)
Young Buck connects with Cap 1 for this new record "Gas Up". Produced by Slade Da Monsta. His Active mixtape with Cub Da CookUp…
2 Chainz, Cap 1, Skooly, Short Dawg & Kaleb – Keep It 100
2 Chainz brings along Cap 1, Skooly, Short Dawg, and Kaleb for "Keep It 100". Look out for his TRU Jack City mixtape on…
2 Chainz – Trap House Stalkin (Feat. Young Dolph & Cap 1)
2 Chainz celebrates the launch of his The Real University record label with "Trap House Stalkin" featuring Young Dolph and Cap 1. The record…
Turk – You Mad Yet (Remix) (Feat. Cap 1, Grafh & Maino)
Turk of Hot Boys returns with the official remix of his "You Mad Yet" track. The song features Cap 1, Maino, and Grafh. Production…
Mike Will Made It – Someone To Love (Feat. 2 Chainz, Skooly & Cap 1) (Official Music Video)
With his Ransom mixtape now available, Mike Will Made It drops off a clip for one of the project's stand outs.
Future "Perkies" (Produced by Metro Boomin)
Debonair Brown "Embrace It" (Official Music Video)
A Boogie Wit da Hoodie "Reply" (Feat. Lil Uzi Vert)
Future "Last Name" (Feat. Lil Durk)
Lil Peep "Everybody's Everything" (Album Stream)
Tory Lanez "Chixtape 5" (Album Stream)
Kanye West "Jesus Is King" (Album Stream)
Kirill & Jaco "Hublot" (Official Music Video)
Lil X "New Kid on the Block" (Album Stream)


text:
British publisher Canongate's "The Myths" is one of the most ambitious and intriguing publication projects of recent years, the sort of undertaking that I wish were more characteristic of the mainstream publishers which have such tremendous connective resources at their disposal. Canongate recruits major authors to write reflections on and retellings of major world myths (so far Ali Smith, Margaret Atwood, Karen Armstrong, Philip Pullman, and Jeanette Winterson have graced the list), and then lead a consortium of 24 publishing houses in releasing the individual "myths" simultaneously worldwide.
The first two works I have read from "The Myths" series - Margaret Atwood's Penelopiad and now Jeanette Winterson's Weight - have made intriguing choices that reveal them as representative members of the arc of the authors' whole body of work. Atwood's novella turns a critical gaze on the misogynistic injustices of Telemachus and Odysseus in Homer's work (where indeed the hostile suspicions the two men hold about Penelope's fidelity are excruciating to witness) and gives a crucial choric voice to the maids they so brutally murder at the epic's end, filled with a gendered viciousness disturbingly out of proportion to the crime committed by the girls. Sadly, for all these interesting moves, I found it to be surprisingly straightforward in its "revisions" of the myth, and not nearly as intricately written as the best of Atwood's novels.
"Weight" also seems a bit like Winterson Lite (I am going to suffer in the Underworld for that pun someday). She weaves some wonderfully surprising strands into the fabric of her tale of burdened Atlas and the repellently phallus-obsessed Hercules (who, you may remember, agrees to take on the weight of the world for Atlas - doomed to hold up the universe for all eternity - while he fetches some golden apples, only to trick poor old Atlas into taking up the world again when he returns with the fruit). Winterson's characteristic self-reflexive move (drawing attention to the ambiguities of her persona as an author) makes an appearance:
There are two facts that all children need to disprove sooner or later; mother and father. If you go one believing the fiction of your own parents, it is difficult to construct a narrative of your own.The traumatizing story of Laika, the first animal sent out into space (and not, crucially, brought home), also makes a strange and not wholly well-integrated appearance in the novel. I couldn't help but recall My Life as a Dog, where a Swedish film where the resonance of Laika's tale with the personal experience of isolation is set up so much less cheesily.
In a way I was lucky. I could not allow my parents to be the facts of my life. Their version of the story was one I could read but not write. I had to tell the story again.*
I am not a Freudian. I don't believe I can mind the strata of the past and drill out the fault lines. There has been too much weathering; ice ages, glacial erosion, meteor impact, plant life, dinosaurs.
The strata of sedimentary rock are like the pages of a book, each with a record of contemporary life written on it. Unfortunately the record is far from complete. (139-140)
Altogether, the different strands don't seem to make the final step to being a coherent or at least finished whole. I don't mean this so much in the sense of narrative incompleteness, because ambiguity and instability are clearly two of Winterson's favorite strategies, but rather (as in the case of The Penelopiad) that this novella always feels like a side-project, written in the margins of the "real books" the authors have underway. They are a bit drafty (in at least two senses of the word), the sentences letting in little gusts of readerly doubt through every slight awkwardness.
Nonetheless, Jeanette Winterson's fragmentary, aphoristic style seems better suited to the project of the mythological novella, being nearer to poetry than the novel. Still in both cases I wish a ruthless editorial hand had questioned the small infelicities of style and the large jarrings of narrative obviousness. There is no reason, in the hands of these skilled and authority-questioning authors, why archetype should settle into stereotype, even for a moment.
Weight (2005)
Jeanette Winterson
March 4, 2008 (Yikes, I have fallen really behind in my reviewing.)
* Winterson's upbringing by her fundamentalist adoptive parents (who were not what you might call comfortable with the emerging knowledge that she was a lesbian, or for that matter a voracious reader of non-Biblical literature) is the subject of her utterly fascinating novel/memoir hybrid, Oranges are not the Only Fruit. I highly recommend it.