. . . would there have been the tech explosion in Silicon Valley?
When i was out at a dot-com one of the guys there said that one of the big reasons that Cali had so much tech stuff so quick is the lack of non-compete agreements. I forgot if they were illegal, or just de-facto unenforcible, but it allowed a person to have a startup in very quick time. If you had a better idea, you could find skilled people in your industry very easily, and you can get started without a great deal of training. Dunno if this is true, but an interesting explanation.
If folks are encumbered by "ideas" that others own, this freedom of movement is obviously curtailed. I wonder if the state of Cali is looking into this, and their position on this. I doubt much, right now the "chilling effect" of owned intellectual property is fairly low on the economic influences in Cali.
Books for classes have been doing this for years. Some have shrinkwrap licenses, though most have software that generally gets unused in the class, but is just there to make resale of the book harder. It's starting a mini-cottage industry of small booksellers that don't care about the license and will buy and sell the used book no matter what, as opposed to the large campus store that needs to comply with the bookseller's corporate "licensing" terms.
Nor would they call their browser Internet Explorer without checking that there was a competing trademark, then after they get sued say in court "Internet Explorer" is too generic to hold a mark, while arguing in different cases that "Windows" is a strong specific mark.
nope, not a word Evidently, you've never been out in the dot-con^Hm world. You'll hear Productization and "monetize eyeballs" 'til the Tucows come home......and no, I'm not bitter, not at all.;)
If there's not a Sol8 package for you, try backwards. Generally, outside of gcc (because of header files) and kernel structure dependant stuff (top) everything is forward compatible.
Aside from the flamewars below (flaming because someone mentioned an MS book? geez), the problem is still yours.
assert() isn't an MSism, it's an ANSI Cism. It specifically tells you it is only used to test code and is stripped out in all compilers if you define NDEBUG, which a VC++ release build does. You just didn't know what assert()s did, nor what a VC++ a release build meant. You can look at the -D flags VC++ sets in release vs. debug bulds (I forgot how, haven't used it since version 4 something).
Since assert() worked properly, it means you coded it wrong. You should have coded this as 1. array = new int[SIZE]; 2. assert(array != NULL); 3. for (int i = 0; i < SIZE; i++) {
The assert() is only a test, and can be safely removed in a VC++ release build.
As a side point, this should never have been an assert() anyway. assert()s are meant for algorithm and data structure consistency checks, where a failed assert() means a programming error. Say, you do a consistency check when adding to a linked list. Look up preconditions and postconditions in any good programming text, there's where you put assert()s.
In this case, it's a run time thing. The assert() fails if we don't have enough memory. Has nothing to do with the correctness of the algorithm, nothing about a bug, just quit other programs or add memory.
As a side note, this is all moot anyway. If this is any recent spec compliant compiler, new will never fail and return NULL, but it will instead throw an exception, which if uncaught, will terminate your program.
1) Make sure you set up your/etc/passwd, I think if you log in locally, it will set it up for you, but if you log in from the net it won't pull in the entire domain (probably for the good). do: mkpasswd -l >/etc/passwd mkpasswd -d -u USERNAME >>/etc/passwd
2) The Cygwin bash term (like if you go to the start menu and get a bash shell) takes the standard ANSI escape sequences. So you can do the normal PROMPT_COMMAND things and have your cwd in the title in the term window. I love this. Problem is, the termcap doesn't seem to totally jibe with termcaps on the Solaris machines I log in to, so I still have to use XTerms if I want scrolling in say man pages to work right. Set this up in the.bashrc, make sure you have a.bash_profile that sources.bashrc. I found out it's not done automatically.
3) cygstart (in the cygutils package) is your friend. It's the glue that integrates the Windows and Cygwin sides well. cygstart --open on a Windows App path will open it in a new window. cygstart --open on a doc will open the doc in the app associated with it in Windows. If you pass in paths from cygwin to a windows app, translate the path before. Here, $(cygpath -w unix_style_path) is your other friend.
4) If you want to open a cygwin app without the attendant DOS window, check out the run utility.
5) Look for "Command Prompt here" on Microsoft web sites. Then open up RegEdit, look for DosHere, and change the command to the path to your bash shell. Then you can open up bash shells in any directory. Nice.
If you were doing this now, I'd say go with Cygwin. It's a normal build of Perl, from perl sources, and you get the whole Cygnus UNIXalike toolkit. it's very good, I even use WindowMaker from Cygwin as my window manager (it looks really cool). ALl of the CPAN stuff just plugs in easily. Same with ActiveState TCL. I use Cygwin tcl/Tk. It works fine.
One thing you might have bumped into was the whole braindead "I only know stuff by filename extensions" that the servers used to do in the early days, before IIS even existested.
This is a joke, I've set up both Linux and FreeBSD, Linux has more apps, FreeBSD is cleaner. I've used Solaris, SCO, Tru64, AIX, HPUX, SunOS, even DG/UX on a Motorla 88K. Pick whatever works best for you and be happy with it.
Mac OS X uses portions of FreeBSD (user land bits mostly), but is built on top of the Mach microkernel.
My understanding of this, is OS X is a hybrid Microkernel, kind of like how NT Microkernel is. In pure MKs, the MK only abstracts the hardware and manages raw hardware resources. Any interpretation is user level. For example, the network adabter driver would be in the kernel, but the TCP/IP stack would be user level. Sometimes it gets kind of slow, because you'd have to pass messages from user level app code through the MK and then to the user level tcp/ip stack, then back though the kernel and back to user-level app. Most MKs in use now are hybrids because of this, thy hybridization is to short circuit the message passing delays. I think Debian on GNU/Hurd is a "pure" MK implementation, using a Debian UNIX "server" to get UNIX APIs and all that under the Hurd.
OS X has a Mach core, but the BSD subsystem is also kernel level. They glue together, it's not just user-level stuff, which has a lot of NeXT thrown in as well. It also started as NetBSD code, I guess for portability reasons, then they realized they liked FreeBSD kernel a bit too, so now the BSD layer is a hybrid NetBSD/FreeBSD 2.x, soon to be FreeBSD 4.x layer.
Zilog tried to get Z (for the Z80, Z8000 line of processors). Judge threw that out, saying if he let thjem do it, it would just take 25 other companies to trademark us out of the English language.
Just a couple random shots to SBUX and their damn sizing schemes, especially "venti".
No real sizes, no "small medium large" like every else on the planet. Ask them for a large, and they look like a deer in headlights for a second, then say "Oh, a venti". Stupid.
Hmmm, venti means 20 in italian:
It's not even 20 all the times. Some stuff is 20 oz, some 24. What gives?
Venti is (TM) Starbucks corporation. They TRADEMARKED a number. I bet Intel is pissed, Starbucks gets venti (TM) and they couldn't get 486. Next time we'll call it the Intel Quatre-Cent Quatre-Vinghts-Six (TM).
Windows downloads reaching 0 for 2001. Well last year, they did have that hole in their mirroring servers that allowed folks to download WindowsXP. And then there's all the warez d00dz....
Do a google lookup on "sprintf exploit" and you'll get a host of vulnerabilities. It's basically a stack smash.
Local variables are on the stack. Say you have some command, and it takes some input from a user, say a command line arg, environment variable, or from a file. In C, all local variables are on the stack. Say you want to sprintf that arg to a buffer on the stack, but assumes a size and never checks it. Then that data will overwrite the return value on the stack. When that function returns, it will not go to the old return address, but some other address that was in the buffer that sprintf wrote too. If you do this right, that return address will go to exploit code.
It's no more exploitable on UNIX than anything else, it's just what can you do with it? If the app taking the input is running as root then you can get root privileges.
My supervisor tried to plug in his brother's PC into the net, it shut down his access port. Then he plugged it into my hub, shut down mine too. Had to call one of the LAN guys to reset all ports in my office. I'm not sure if they filter by allowed companies and all NICs have to be Intels or whatever, or they have a complete table of allowed MAC addresses, but either way this wouldn't work on my network.
Chrylser tried this buzz thing by stocking PT Cruisers at rental car locations in hip parts of Miami.
Isn't this kind of normal? Hertz is owned by Ford (GT350H, man was that a car) and rents Fords "and other fine cars". Lots of unsold and recently used cars (demos and such) cars go to the rental places. I'm not sure if this case is buzz marketing or S.O.P. Some criticize this because it inflates car sales - I think the Taurus sales figures when it was #1 sold car included "fleet sales" such as these.
Apple got PowerPC religion within the 7.1 series, actually going from 7.1 to 7.1.2. 7.0 was a huge jump. 7.1 fixed the massive amount of bugs in 7.0 (well a reasonable subset anyway). System 7 had things called System Enablers. Enablers were Apple's idea of separating the hardware specific parts of the OS into one file, and all the rest is universal. It sucked because then you couldn't have a universal system on a floppy (wow, you could get MacOS on a single floppy once? yes my son). You couldn't fit all the enablers on one floppy with the kernel, especially with the huge 7.1.2 enabler (see below).
7.1.2 essentially added support for PowerPC with a 68040LC Emulator. Very little of the OS was PowerPC then, they were just glad to get anything to work. Once that was kinda stable, then speed sensitive stuff went PowerPC native. I think Quicktime went first. There was something in each code segment that said whether it was 68040 or PowerPC. Each app could have mixed segments, as could the kernel.
Considering Apple added a whole new chip architecture, they're to be commended on how well it worked out. And they did it on the heels of a major upgrade 6->7 (yes, I'm sure they wrote 7.0 with PowerPC in mind, but there wasn't much time between 7.0 and 7.1 to get everything right). Sure 7.1.2 was shit, and it really didn't get together til 7.5 series (how 7.5.3!) but it was a whole new chipset that required changes to the kernel and code segment loaders and having all these segments talk to each other. And considering they had to do these with 60MHz (in the first 6100) PowerPC 601s, not exactly screamers. They did pretty well.
In Linux and Windows, is the kernel limited to 4Gb of real memory, or are there higher limtis and the process can only address 4Gb. I remember in WinNT the kernel addresses 2GB of virtual, and a process 2Gb of virtual, and WinNT advance Server, the kernel addresses 1gb and 3Gb process. Have these changed?
Programmer time is expensive; conserve it in preference to machine time,
In the early minicomputer days of Unix, this was still a fairly radical idea (machines were a great deal slower and more expensive then). Nowadays, with every development shop and most users (apart from the few modeling nuclear explosions or doing 3D movie animation) awash in cheap machine cycles, it may seem too obvious to need saying.
Somehow, though, practice doesn't seem to have quite caught up with reality. If we took this maxim really seriously throughout software development, the percentage of application written in higher-level languages like Perl, TCL, Python, Java, and Lisp that ease the programmer's burden by doing their own memory management would be rising fast.
And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++). Later in this book we'll discuss this strategy and its tradeoffs in detail.
One other obvious way to conserve programmer time is to teach machines how to do more of the low-level work of programming. This leads to...
Valgrind doesn't work on Solaris, so I'm stuck with Purify for my day job.
Is it possible to have your code portable to both OSes so you can run the tool, or will the higher ups feel this isn't a workable solution. I obviously have no idea of what you're doing, nor the effort of porting, just an idea to throw out. You might be able to say that you save debug time, and get a Linux version of their software in the process.
I think this is a bit misleading, it's actually a Linux/x86 virtual machine. valgrind is an environment, not just a library you link to. You don't "enable" it on your binary, you need to specifically run something under this VM. It's more akin to running something through the debugger "hey, lets do our daily/weekly valgrind run" than something you could run all the time. Or maybe do it when you have specific errors and wnat to smoke them out. It's a totally different type of tool.
I think the VM concept is quite clever. It would be interesting to see debates about it. On the good side, it cheks EVERYTHING, not just stuff you turned the switch on for. Even bad system libraries (it has switches to turn these off so you don't get deluged by them). On the bad side, it's obviously Linux/x86 only. I guess it pays to keep your code portable. I'm in a SPARC/Solaris only shop, but I could see myself keeping things portable to linux enough to run this, say once a week to ferret out bugs.
I can't find my "learning to program the Macintosh with ThinkC!"
Re:Not convinced at all
on
Think Python
·
· Score: 2
I got put off by just the second paragraph:
or why teach programming with Python?" Answering these questions is no simple task - especially when popular opinion is on the side of more masochistic alternatives such as C++ and Java.
It manages to make two derogatory statements. That programming in C++/Java is masochistic (thats a subject of opinion, so I can let it slide) and makes a subtle barb that they're used because they're popular and not because of merit. It just poked of programming religion to me. I'm very much a "use the right tool for the job" guy. I haven't used Python, so I'm a little cautious about talking about it, but I'm fairly confident saying they're are a lot more C and C++ libraries available to a C++ programmer than off the shelf Python packages.
This is valid IF 1) All the code in OpenBSD is bugree. the recent OpenSSH hole shows this isn't the case. I'm pretty sure OpenSSH was fairly heavily audited too, and it still had a hole. The new permission separation code can help here, but OpenBSD still had a remote root exploit.
2) You NEVER have any code running thats not in the default install. Means no Apache (which had a quickly patched hole recently), no configuring your system, cause as soon as you do, you're running other code. eg. you can configure telnet to run when it wasn't running in the default install. You can misconfigure OpenBSD just as easily as any other UNIX, it just starts with safer defaults.
Code audits are like perimeter locks. It stops people from getting in. Security models are more like internal locks and safes. Once you get in, it limits what you can take. They aren't mutually exclusive.
Slashdot Mirror
. . . would there have been the tech explosion in Silicon Valley?
When i was out at a dot-com one of the guys there said that one of the big reasons that Cali had so much tech stuff so quick is the lack of non-compete agreements. I forgot if they were illegal, or just de-facto unenforcible, but it allowed a person to have a startup in very quick time. If you had a better idea, you could find skilled people in your industry very easily, and you can get started without a great deal of training. Dunno if this is true, but an interesting explanation.
If folks are encumbered by "ideas" that others own, this freedom of movement is obviously curtailed. I wonder if the state of Cali is looking into this, and their position on this. I doubt much, right now the "chilling effect" of owned intellectual property is fairly low on the economic influences in Cali.
Books for classes have been doing this for years. Some have shrinkwrap licenses, though most have software that generally gets unused in the class, but is just there to make resale of the book harder. It's starting a mini-cottage industry of small booksellers that don't care about the license and will buy and sell the used book no matter what, as opposed to the large campus store that needs to comply with the bookseller's corporate "licensing" terms.
Nor would they call their browser Internet Explorer without checking that there was a competing trademark, then after they get sued say in court "Internet Explorer" is too generic to hold a mark, while arguing in different cases that "Windows" is a strong specific mark.
nope, not a word ...and no, I'm not bitter, not at all. ;)
Evidently, you've never been out in the dot-con^Hm world. You'll hear Productization and "monetize eyeballs" 'til the Tucows come home...
SunFreeware
If there's not a Sol8 package for you, try backwards. Generally, outside of gcc (because of header files) and kernel structure dependant stuff (top) everything is forward compatible.
Aside from the flamewars below (flaming because someone mentioned an MS book? geez), the problem is still yours.
assert() isn't an MSism, it's an ANSI Cism. It specifically tells you it is only used to test code and is stripped out in all compilers if you define NDEBUG, which a VC++ release build does. You just didn't know what assert()s did, nor what a VC++ a release build meant. You can look at the -D flags VC++ sets in release vs. debug bulds (I forgot how, haven't used it since version 4 something).
Since assert() worked properly, it means you coded it wrong. You should have coded this as
1. array = new int[SIZE];
2. assert(array != NULL);
3. for (int i = 0; i < SIZE; i++) {
The assert() is only a test, and can be safely removed in a VC++ release build.
As a side point, this should never have been an assert() anyway. assert()s are meant for algorithm and data structure consistency checks, where a failed assert() means a programming error. Say, you do a consistency check when adding to a linked list. Look up preconditions and postconditions in any good programming text, there's where you put assert()s.
In this case, it's a run time thing. The assert() fails if we don't have enough memory. Has nothing to do with the correctness of the algorithm, nothing about a bug, just quit other programs or add memory.
As a side note, this is all moot anyway. If this is any recent spec compliant compiler, new will never fail and return NULL, but it will instead throw an exception, which if uncaught, will terminate your program.
Some random tips...
/etc/passwd, I think if you log in locally, it will set it up for you, but if you log in from the net it won't pull in the entire domain (probably for the good). do: /etc/passwd /etc/passwd
.bashrc, make sure you have a .bash_profile that sources .bashrc. I found out it's not done automatically.
1) Make sure you set up your
mkpasswd -l >
mkpasswd -d -u USERNAME >>
2) The Cygwin bash term (like if you go to the start menu and get a bash shell) takes the standard ANSI escape sequences. So you can do the normal PROMPT_COMMAND things and have your cwd in the title in the term window. I love this. Problem is, the termcap doesn't seem to totally jibe with termcaps on the Solaris machines I log in to, so I still have to use XTerms if I want scrolling in say man pages to work right. Set this up in the
3) cygstart (in the cygutils package) is your friend. It's the glue that integrates the Windows and Cygwin sides well. cygstart --open on a Windows App path will open it in a new window. cygstart --open on a doc will open the doc in the app associated with it in Windows. If you pass in paths from cygwin to a windows app, translate the path before. Here, $(cygpath -w unix_style_path) is your other friend.
4) If you want to open a cygwin app without the attendant DOS window, check out the run utility.
5) Look for "Command Prompt here" on Microsoft web sites. Then open up RegEdit, look for DosHere, and change the command to the path to your bash shell. Then you can open up bash shells in any directory. Nice.
If you were doing this now, I'd say go with Cygwin. It's a normal build of Perl, from perl sources, and you get the whole Cygnus UNIXalike toolkit. it's very good, I even use WindowMaker from Cygwin as my window manager (it looks really cool). ALl of the CPAN stuff just plugs in easily. Same with ActiveState TCL. I use Cygwin tcl/Tk. It works fine.
One thing you might have bumped into was the whole braindead "I only know stuff by filename extensions" that the servers used to do in the early days, before IIS even existested.
Hell, I was karma capped for a while, I can live with the negative mods...
Take it tux
This is a joke, I've set up both Linux and FreeBSD, Linux has more apps, FreeBSD is cleaner. I've used Solaris, SCO, Tru64, AIX, HPUX, SunOS, even DG/UX on a Motorla 88K. Pick whatever works best for you and be happy with it.
Mac OS X uses portions of FreeBSD (user land bits mostly), but is built on top of the Mach microkernel.
My understanding of this, is OS X is a hybrid Microkernel, kind of like how NT Microkernel is. In pure MKs, the MK only abstracts the hardware and manages raw hardware resources. Any interpretation is user level. For example, the network adabter driver would be in the kernel, but the TCP/IP stack would be user level. Sometimes it gets kind of slow, because you'd have to pass messages from user level app code through the MK and then to the user level tcp/ip stack, then back though the kernel and back to user-level app. Most MKs in use now are hybrids because of this, thy hybridization is to short circuit the message passing delays. I think Debian on GNU/Hurd is a "pure" MK implementation, using a Debian UNIX "server" to get UNIX APIs and all that under the Hurd.
OS X has a Mach core, but the BSD subsystem is also kernel level. They glue together, it's not just user-level stuff, which has a lot of NeXT thrown in as well. It also started as NetBSD code, I guess for portability reasons, then they realized they liked FreeBSD kernel a bit too, so now the BSD layer is a hybrid NetBSD/FreeBSD 2.x, soon to be FreeBSD 4.x layer.
I remember this, the whole i486 thing.
Zilog tried to get Z (for the Z80, Z8000 line of processors). Judge threw that out, saying if he let thjem do it, it would just take 25 other companies to trademark us out of the English language.
- No real sizes, no "small medium large" like every else on the planet. Ask them for a large, and they look like a deer in headlights for a second, then say "Oh, a venti". Stupid.
Hmmm, venti means 20 in italian:Windows downloads reaching 0 for 2001.
Well last year, they did have that hole in their mirroring servers that allowed folks to download WindowsXP. And then there's all the warez d00dz....
I'm sure the number > 0
Do a google lookup on "sprintf exploit" and you'll get a host of vulnerabilities. It's basically a stack smash.
Local variables are on the stack. Say you have some command, and it takes some input from a user, say a command line arg, environment variable, or from a file. In C, all local variables are on the stack. Say you want to sprintf that arg to a buffer on the stack, but assumes a size and never checks it. Then that data will overwrite the return value on the stack. When that function returns, it will not go to the old return address, but some other address that was in the buffer that sprintf wrote too. If you do this right, that return address will go to exploit code.
It's no more exploitable on UNIX than anything else, it's just what can you do with it? If the app taking the input is running as root then you can get root privileges.
My supervisor tried to plug in his brother's PC into the net, it shut down his access port. Then he plugged it into my hub, shut down mine too. Had to call one of the LAN guys to reset all ports in my office. I'm not sure if they filter by allowed companies and all NICs have to be Intels or whatever, or they have a complete table of allowed MAC addresses, but either way this wouldn't work on my network.
Chrylser tried this buzz thing by stocking PT Cruisers at rental car locations in hip parts of Miami.
Isn't this kind of normal? Hertz is owned by Ford (GT350H, man was that a car) and rents Fords "and other fine cars". Lots of unsold and recently used cars (demos and such) cars go to the rental places. I'm not sure if this case is buzz marketing or S.O.P. Some criticize this because it inflates car sales - I think the Taurus sales figures when it was #1 sold car included "fleet sales" such as these.
Millions of DEBUG and WINDOWS jokes to follow...
Apple got PowerPC religion within the 7.1 series, actually going from 7.1 to 7.1.2. 7.0 was a huge jump. 7.1 fixed the massive amount of bugs in 7.0 (well a reasonable subset anyway). System 7 had things called System Enablers. Enablers were Apple's idea of separating the hardware specific parts of the OS into one file, and all the rest is universal. It sucked because then you couldn't have a universal system on a floppy (wow, you could get MacOS on a single floppy once? yes my son). You couldn't fit all the enablers on one floppy with the kernel, especially with the huge 7.1.2 enabler (see below).
7.1.2 essentially added support for PowerPC with a 68040LC Emulator. Very little of the OS was PowerPC then, they were just glad to get anything to work. Once that was kinda stable, then speed sensitive stuff went PowerPC native. I think Quicktime went first. There was something in each code segment that said whether it was 68040 or PowerPC. Each app could have mixed segments, as could the kernel.
Considering Apple added a whole new chip architecture, they're to be commended on how well it worked out. And they did it on the heels of a major upgrade 6->7 (yes, I'm sure they wrote 7.0 with PowerPC in mind, but there wasn't much time between 7.0 and 7.1 to get everything right). Sure 7.1.2 was shit, and it really didn't get together til 7.5 series (how 7.5.3!) but it was a whole new chipset that required changes to the kernel and code segment loaders and having all these segments talk to each other. And considering they had to do these with 60MHz (in the first 6100) PowerPC 601s, not exactly screamers. They did pretty well.
In Linux and Windows, is the kernel limited to 4Gb of real memory, or are there higher limtis and the process can only address 4Gb. I remember in WinNT the kernel addresses 2GB of virtual, and a process 2Gb of virtual, and WinNT advance Server, the kernel addresses 1gb and 3Gb process. Have these changed?
Valgrind doesn't work on Solaris, so I'm stuck with Purify for my day job.
Is it possible to have your code portable to both OSes so you can run the tool, or will the higher ups feel this isn't a workable solution. I obviously have no idea of what you're doing, nor the effort of porting, just an idea to throw out. You might be able to say that you save debug time, and get a Linux version of their software in the process.
I think this is a bit misleading, it's actually a Linux/x86 virtual machine. valgrind is an environment, not just a library you link to. You don't "enable" it on your binary, you need to specifically run something under this VM. It's more akin to running something through the debugger "hey, lets do our daily/weekly valgrind run" than something you could run all the time. Or maybe do it when you have specific errors and wnat to smoke them out. It's a totally different type of tool.
I think the VM concept is quite clever. It would be interesting to see debates about it. On the good side, it cheks EVERYTHING, not just stuff you turned the switch on for. Even bad system libraries (it has switches to turn these off so you don't get deluged by them). On the bad side, it's obviously Linux/x86 only. I guess it pays to keep your code portable. I'm in a SPARC/Solaris only shop, but I could see myself keeping things portable to linux enough to run this, say once a week to ferret out bugs.
I can't find my "learning to program the Macintosh with ThinkC!"
This is valid IF
1) All the code in OpenBSD is bugree. the recent OpenSSH hole shows this isn't the case. I'm pretty sure OpenSSH was fairly heavily audited too, and it still had a hole. The new permission separation code can help here, but OpenBSD still had a remote root exploit.
2) You NEVER have any code running thats not in the default install. Means no Apache (which had a quickly patched hole recently), no configuring your system, cause as soon as you do, you're running other code. eg. you can configure telnet to run when it wasn't running in the default install. You can misconfigure OpenBSD just as easily as any other UNIX, it just starts with safer defaults.
Code audits are like perimeter locks. It stops people from getting in. Security models are more like internal locks and safes. Once you get in, it limits what you can take. They aren't mutually exclusive.