Slashdot Mirror

Give OpenBSD a try.

Performs very well on old and stripped down hardware, has a simple and quick instalation and the best documentation available on open systems. Take a look on their FAQ

NetBSD has more aplications available and can be installed
in many hardwares with very tiny disks, but I personally prefer OpenBSD.

Give OpenBSD a try.

Performs very well on old and stripped down hardware, has a simple and quick instalation and the best documentation available on open systems. Take a look on their FAQ

NetBSD has more aplications available and can be installed
in many hardwares with very tiny disks, but I personally prefer OpenBSD.

I would prefer operating system vendors to treat security as part of the core functionality of their products.

Some do.

Hey, Debian isn't bloated! :-)

NetBSD does rock though. They don't even have perl in the base system. I used to hate that, but then I realized... hey... I can install perl 5.8.0 or 6 without having to "hide" it from the system software (like I have to on FreeBSD -- PATH=/usr/local/bin:/usr/bin:/bin -- oops, wrong perl *barf* -- ::shudder::). Plus they include Postfix, how cool is that?

And to top it all off, they don't have Theo the Rat, unlike this supposedly "secure" OS.

Yep, I'm a troll, but OpenBSD is my OS of choice.

• Screaming Electron - Excellent message board
  
• Nomoa BSD - Slightly out-of-date but still a good resource
  
• OpenBSD Journal - Great OpenBSD news site
  
• subscribe to the Mailing Lists
  

More notice for dropping support? Isn't there stated policy that they support only the current release and the previous release? Look at the fancy ASCII map of their release schedule. It clearly shows that only two releases are maintained at one time. I've been using OpenBSD since 2.9, and I was always aware of their support scheme. Where have you been?

Do you assume that they have the resources to support older releases just because it is an inconvenience for your to upgrade? They are offering you a really great OS for free. They work really hard to make sure that it is the best it can be. And what I like most about the OpenBSD team is that they really take a stand for freedom issues in software (read Theo's stance on the Sun ECC code being included in OpenSSL in this message, or check out the entire thread).

Give these guys a break. You had 6 months to test 3.1 and upgrade your boxes from 3.0. If you don't like their policy, use something else. As someone said over a deadly.org, if you want support for older releases, pay someone to provide patches for your system. Whatever you decide to do, stop complaining about something they give away for free.

No, dont download it. Buy it! Support the brave people how work hard to get openbsd to work!

Binary works kind of well.

Renaming (in general) sort of works, but you lose
the earlier names, or the history. I usually mv the
RCS files if it's not a big deal.
Also, with a bit of inter-developer action, you
could tag the tree before the rename, and after,
so everyone could diff his changes. Oh, wait.

You missed the big scary missing point of cvs
(after renaming): disconnected operation.

See, a developer at flight cannot simply check in.
Even if he has a local copy of the master repo, he
would need to preserve it, etc etc, with many
hassles.
I first encountered it getting the OpenBSD source
via CTM, by retrieving
the full repository. CTM cannot update any more when
you modificate the files (ok there is some mechanism
to circumvent that, but xxx,v.ctm is just ugly).

Some OpenBSD developer told me in IRC (#OpenBSD on
OpenProjects.net (www.freenode.net)) that they will
switch to OpenCM in some years when it is more mature.
(it became a port some days later...) which is said
to be better. They will not use any of the other CMS,
he added.

Maybe this helps.

Binary works kind of well.

Renaming (in general) sort of works, but you lose
the earlier names, or the history. I usually mv the
RCS files if it's not a big deal.
Also, with a bit of inter-developer action, you
could tag the tree before the rename, and after,
so everyone could diff his changes. Oh, wait.

You missed the big scary missing point of cvs
(after renaming): disconnected operation.

See, a developer at flight cannot simply check in.
Even if he has a local copy of the master repo, he
would need to preserve it, etc etc, with many
hassles.
I first encountered it getting the OpenBSD source
via CTM, by retrieving
the full repository. CTM cannot update any more when
you modificate the files (ok there is some mechanism
to circumvent that, but xxx,v.ctm is just ugly).

Some OpenBSD developer told me in IRC (#OpenBSD on
OpenProjects.net (www.freenode.net)) that they will
switch to OpenCM in some years when it is more mature.
(it became a port some days later...) which is said
to be better. They will not use any of the other CMS,
he added.

Maybe this helps.

They were right to refuse code with insecure licences
(Theo removed many code from OpenBSD because
of licence issues) and tell us that Linux is non-free
(remember the story about RMS telling us that bitkeeper
and vendor-supplied scsi code are unfree?)

I knew that Theo was right, even if I have my small
struggles with him, too.
If people want to try out free operating systems with
fewer licence issues, try out OpenBSD.

NetBSD still uses IPFilter (by Darren Reed) which
started the licence questioning in OpenBSD, and at
least FreeBSD 4.x has patented SMP code from BSD/OS
in it (that's why they started SMPng IIRC).

No. Here. Patch.

Finally OpenBSD will ahve some straight up competition. For a long time it has been the most secure, and the only BSD with SMP support.

Can't wait to see what FreeBSD does to top this!

Finally OpenBSD will ahve some straight up competition. For a long time it has been the most secure, and the only BSD with SMP support.

Can't wait to see what FreeBSD does to top this!

The rest of the world *does* exist you know.

I've been a longtime x86 user, and if it wasn't for BSD this would be enough to get me to switch to Mac

How about NetBSD or OpenBSD?

Heck you can even run Linus' OS (I forget the name) :)

By your logic, "BSD" isn't anywhere on FreeBSD.org or OpenBSD.org if it shows the description.

Hi werdna,

You wrote:

Reasonable people may differ with our anonymous coward about whether discounting his 1990 suggestion constitutes ignoring the entire Unix market, or whether he simply has an overblown view of the representattive constituency of his own design choices as compared to those of others.

You make a good point. My personal design choices don't represent the entire Unix market. I grant that.

Many Unix users are young, and learned with Linux or FreeBSD on IBM compatible hardware. For some of them, the IBM AT keyboard layout is OK.

Many other unix users were using Unix (or CP/M or VMS) systems long before the IBM AT, and grew accustomed to a keyboard layout having Ctrl to the left of the A key. Many of these people share my desire for a solution to the "ADB keyboard problem".

Executive Summary:

I am the anonymous coward who posted "Apple Laptop Keyboards Unsuitable for Unix Users". I am not the author of the UseNET post asking how to re-map the CapsLock key on an Apple Macintosh back in 1990. My point is that Apple's design choices back in the mid-80's are having very negative effects now. (They were having negative effects back in 1990 as well, as the UseNET post indicates.)

Additional evidence that other long-time Unix users share my need for a Ctrl key to the left of the A key is the fact that soon after IBM re-designed the keyboard layout for their IBM AT in 1984, unix man pages started to include sections on how to re-map the CapsLock key. For modern examples, see xmodmap(1), pckbd(4), wsconsctl(8), and XF86Config(5).

All Apple laptops still have ADB keyboards, and have a design flaw that prevents re-mapping the CapsLock key with software. If Apple really wants to expand into the Unix market, they should correct this problem.

Not all Unix people absolutely need a Ctrl key to the left of the A like I do, but a significant number do. Those people can't effectively use Apple laptops.

Historical Background:

Back in 1984, when the IBM AT first came out, IBM correctly recognized that the killer-app was word processing. IBM chose to have a keyboard layout that closely matched the IBM Selectric typewriter. They placed CapsLock to the left of the A key.

I think IBM's choice was a mistake. The Ctrl key was very heavily used in unix, CP/M, and even in DOS in those days. By placing the Ctrl key in an ergonomically very hard to reach place they discouraged its use. I don't think that this was the intention of the IBM people who made this decision; it was a consequence they didn't foresee. There are many other ways to achieve the functionality of CapsLock, but no other ergonomically good ways to achieve the meta- functionality of the Ctrl key. So, IBM foisted a bad keyboard layout upon us.

Apple followed IBM down the route to keyboard layout perdition, but they made the problem much worse! Apple not only copied IBM's (bad in my opinion) layout, but they also designed the ADB keyboard such that it was not possible to re-map the layout in software. You can re-map every key on every IBM compatible keyboard, and every key except CapsLock on the ADB keyboards. You ought to be able to re-map the CapsLock key as well! Preventing this was Apple's horribly bad mistake.

The original Apple ADB keyboards were not like this. They had a layout like all IBM XT keyboards, with the Ctrl key to the left of the A. The first ADB keyboards didn't even have a CapsLock key. However, when Apple added a CapsLock key, they also botched the design of the keyboard. They made the CapsLock key operate as if it was an actual hardware-locking typewriter key.

Proper Keyboard Design:

• When a key is pressed, the keyboard sends a keyPress event.
• When a key is released, the keyboard sends a keyRelease event.
• Each key is assigned a different keycode.

ADB Keyboard Mis-design:

• When the key to the left of the 'A' (CapsLock) is pressed, the ADB keyboard sends both a keyPress event and a keyRelease event.
• When the CapsLock key is then released, the ADB keyboard sends NO events.
• When the CapsLock key is next pressed, the ADB keyboard sends NO events.
• When the CapsLock key is then released, the ADB keyboard sends both a keyPress event and a keyRelease event.
• The above cycle repeats over and over.

Now, you and I may differ on the best layout. However, designing a keyboard that prevents re-mapping cannot be defended!

The Unix users who don't care about keyboard layout can use Apple's laptops as they currently exist. I know some of them.

For those Unix users (and there are many) who depend upon the Ctrl key being to the left of the A key, current Apple laptop hardware is unusable. For these folks, it doesn't matter if they are using vi or emacs; the keyboard layout must satisfy ergonomic requirements. It must be possible to re-map the CapsLock key. These users currently go elsewhere for their (laptop) computer hardware. Apple loses sales to these people.

Hi werdna,

You wrote:

Reasonable people may differ with our anonymous coward about whether discounting his 1990 suggestion constitutes ignoring the entire Unix market, or whether he simply has an overblown view of the representattive constituency of his own design choices as compared to those of others.

You make a good point. My personal design choices don't represent the entire Unix market. I grant that.

Many Unix users are young, and learned with Linux or FreeBSD on IBM compatible hardware. For some of them, the IBM AT keyboard layout is OK.

Many other unix users were using Unix (or CP/M or VMS) systems long before the IBM AT, and grew accustomed to a keyboard layout having Ctrl to the left of the A key. Many of these people share my desire for a solution to the "ADB keyboard problem".

Executive Summary:

I am the anonymous coward who posted "Apple Laptop Keyboards Unsuitable for Unix Users". I am not the author of the UseNET post asking how to re-map the CapsLock key on an Apple Macintosh back in 1990. My point is that Apple's design choices back in the mid-80's are having very negative effects now. (They were having negative effects back in 1990 as well, as the UseNET post indicates.)

Additional evidence that other long-time Unix users share my need for a Ctrl key to the left of the A key is the fact that soon after IBM re-designed the keyboard layout for their IBM AT in 1984, unix man pages started to include sections on how to re-map the CapsLock key. For modern examples, see xmodmap(1), pckbd(4), wsconsctl(8), and XF86Config(5).

All Apple laptops still have ADB keyboards, and have a design flaw that prevents re-mapping the CapsLock key with software. If Apple really wants to expand into the Unix market, they should correct this problem.

Not all Unix people absolutely need a Ctrl key to the left of the A like I do, but a significant number do. Those people can't effectively use Apple laptops.

Historical Background:

Back in 1984, when the IBM AT first came out, IBM correctly recognized that the killer-app was word processing. IBM chose to have a keyboard layout that closely matched the IBM Selectric typewriter. They placed CapsLock to the left of the A key.

I think IBM's choice was a mistake. The Ctrl key was very heavily used in unix, CP/M, and even in DOS in those days. By placing the Ctrl key in an ergonomically very hard to reach place they discouraged its use. I don't think that this was the intention of the IBM people who made this decision; it was a consequence they didn't foresee. There are many other ways to achieve the functionality of CapsLock, but no other ergonomically good ways to achieve the meta- functionality of the Ctrl key. So, IBM foisted a bad keyboard layout upon us.

Apple followed IBM down the route to keyboard layout perdition, but they made the problem much worse! Apple not only copied IBM's (bad in my opinion) layout, but they also designed the ADB keyboard such that it was not possible to re-map the layout in software. You can re-map every key on every IBM compatible keyboard, and every key except CapsLock on the ADB keyboards. You ought to be able to re-map the CapsLock key as well! Preventing this was Apple's horribly bad mistake.

The original Apple ADB keyboards were not like this. They had a layout like all IBM XT keyboards, with the Ctrl key to the left of the A. The first ADB keyboards didn't even have a CapsLock key. However, when Apple added a CapsLock key, they also botched the design of the keyboard. They made the CapsLock key operate as if it was an actual hardware-locking typewriter key.

Proper Keyboard Design:

• When a key is pressed, the keyboard sends a keyPress event.
• When a key is released, the keyboard sends a keyRelease event.
• Each key is assigned a different keycode.

ADB Keyboard Mis-design:

• When the key to the left of the 'A' (CapsLock) is pressed, the ADB keyboard sends both a keyPress event and a keyRelease event.
• When the CapsLock key is then released, the ADB keyboard sends NO events.
• When the CapsLock key is next pressed, the ADB keyboard sends NO events.
• When the CapsLock key is then released, the ADB keyboard sends both a keyPress event and a keyRelease event.
• The above cycle repeats over and over.

Now, you and I may differ on the best layout. However, designing a keyboard that prevents re-mapping cannot be defended!

The Unix users who don't care about keyboard layout can use Apple's laptops as they currently exist. I know some of them.

For those Unix users (and there are many) who depend upon the Ctrl key being to the left of the A key, current Apple laptop hardware is unusable. For these folks, it doesn't matter if they are using vi or emacs; the keyboard layout must satisfy ergonomic requirements. It must be possible to re-map the CapsLock key. These users currently go elsewhere for their (laptop) computer hardware. Apple loses sales to these people.

Sun needs a transition plan to make migration from the low end Linux/x86 based desktops and servers to their Solaris/Sparc based high end workstations and enterprise servers. Otherwise they will not be able to bring as much sales up to the higher tier. There are two ways to do this. One is to run Solaris on x86 hardware as the middle tier. The other is to run Linux on Sparc hardware as the middle tier. One of these approaches leaves Sun subject to the whims of another CPU maker, which has it's own plans for 64-bit domination. The other leaves Sun subject to the whims of a huge open source software community and a few choices in Linux distributions (such as Debian, Mandrake, and SuSE) as well as FreeBSD, NetBSD, and OpenBSD. Which way do you think would be better for Sun?

OpenBSD's other strength is that it is rapidly gaining on NetBSD where being able to run on many different hardware platforms is concerned.

Considering OpenBSD and NetBSD are closely related, there's plenty of cross-pollination between the two. NetBSD may have hpcmips, but OpenBSD has mvme88k. it really is a shame both sides couldn't come to some kind of agreement and make up for past behavior, but until then, the CVS trees on both sides are world-readable. :)

Stupid troll.

Look here [netcraft.com]. Just give up on bsd. It really is dead and the proof is in the pudding.

No, he doesn't. He doesn't personally host openbsd.org. This is in the FAQ.

If you're going to fucking troll, try and get it right.

Runs like a charm on the Sparc 5's and 10's

The worm may only spread through Linux hosts (I don't know, so I can't say for sure), but i'm certain the flaws in OpenSSL are not OS dependent.

The OpenBSD team released a patch about a month ago that fixed these overruns in OpenBSD installations. For those who care to look, it's security patch #13 of the 3.1 errata.

If you want to see how tracking your config from CVS would look, the BSD folks have the entire source for their systems in CVS.

Here's the complete history of all changes to the default /etc/crontab since OpenBSD was forked.

OpenBSD webCVS interface

Eventually Apple should either port Aqua to Linux/X11 or to give up Mac OS at all.

• The BSD-style program run by /sbin/init
• The Plan 9 shell

Couldn't you have been just a little more creative in coming up with a name? Geez. Now we get:

---So how do i do this Red Carpet update thing again?
---rc channels to list the available channels.
[pause]
---It says channels: No such file or directory
---Huh? That's weird...

> Let me start by saying I'm all for Open Source software

That's it. You don't grok free software. It is not the same thing philosophically.

> Oh grow up!

I'm amazed my maturity interests you, but I am 30, have a job and a family, and have had some pretty good education, including some reading in Philosophy. Now on to the debate.

> Think for a moment about who you're freeing.

The users, and in the measure in which government has grown dependent on Informatics, the people.

> Most corporations are given the right to modify programs to fit their individual needs.

No, they aren't. I work at a big European telecom operator, and we have neither the Microsoft source code nor the Amdocs (our billing system vendor) one. Now, I think it is self-defeating proposition to run a business without the source code to one's core system, as is a billing system to a telecom operator. But the incredible thing is that MBAs think it is good. No need to tell you how much shareholders' money is wasted.

> The average consumer doesn't know source code from techno-bable. They couldn't change or modify their programs any way.

The main purpose of source code is not modifying it, but avoiding proprietary lock-in. Please educate yourself.

> now stop fighting the licence war

If we allow everyone to hoard software and claim it's free or open or standard, like Apple and the Unix vendors and Microsoft all have done, we loose our freedom again.

> make your products useable.

That needs efforts currently wasted on useless forking, semi-free code and proprietary systems interoperability.

> So then why are people complaining when Apple and other companies release the sorce to programs?

They didn't. Apple released under a quasi-free license mostly that was already available under a really free license.

> Just because it isn't GPL licensed?

No, because it is not free.

> You can't have consensus because different people want different things.

Yes, but most forking is not because of different, valid goals: it is because of bad technical decisions (for instance RPM as a dpkg fork), proprietary licensing (for instance the original TrollTech Qt licensing) or just the not-invented-here syndrome.

> Freedom and Security are on to ends of a scale. There has to be a balance. Complete freedom means no security, complete security means no freedom, but you have to provide a reason.

Go educate yourself about risks and security. Usually free software is more secure than equivalent proprietary software.

> Safety, if M$ Office breaks, theres technical assistance for them.

There isn't. There is no warranty, there is no security, there is no source code to fix things. There are thousands of people who know a little about MS Office, but no one has the source code. The end result is that people learn to live with brokenness in proprietary programs, while with free software it can always be fixed.

> Ease of use, most OSS software is nice sometime seven great once it's running, but getting it up and running is a pain.

This is being addressed by several distributions. Rome wasn't built in one day.

> Extra steps, as nice as the OSS office suite is, the users still have to select M$ Office format to save their documents so everyone else can read them.

This is because MS Office documents are proprietary. If they were open standards, there would be no need of converstion. But still, if things are saved in XHTML, PDF, RTF and the like, MS Office users can read them.

I don't know why I loose time trying to teach people who can't to their homework reading.

• Intel SE440BX-2 motherboard
• 
  2 - 4 Intel 82557/82558/82559 Intel NICs (Dime a dozen)
  Cisco 16MB PIX Flash card (most expensive bit and the hardest to source)
  Floppy drive
  Case/power supply
  128MB PC100 SDRAM
  350MHZ Processor w/ 512K cache (clock speed doesnt really matter, but watch out over 750 as the board may not support it)
  Serial->Console adaptor (for console access)(you might also want an AGP video card to start with, to make sure the bios doesnt have any whacky settings - but be warned, the pix WONT boot with a video card inserted.

• 
  Pix OS (obtainable from CCO, or your nearest Cisco warez monkey)
  
  Pix Boothelper (Ditto)

• 
  Using dd (on Unix or workalike):
  • 
    dd if=bh61.bin of=/dev/fd0a (/dev/fd0 on Linux)
  
  Using ntrw.exe (on Windows):
  • 
    ntrw bh61.bin A:

• 
  pixboothelper>

• 
  address ip-address (ie "address", followed by the IP address of the inside interface (same subnet as tftp server)
  
  server tftp-ip-address (ie "server", followed up the IP address of the tftp server)
  file pix-os-filename (ie "file", follwed by the Pix OS filename (eg pix622.bin))
  
  then type:tftp
  
  and hit enter to begin the transfer.

• Intel SE440BX-2 motherboard
• 
  2 - 4 Intel 82557/82558/82559 Intel NICs (Dime a dozen)
  Cisco 16MB PIX Flash card (most expensive bit and the hardest to source)
  Floppy drive
  Case/power supply
  128MB PC100 SDRAM
  350MHZ Processor w/ 512K cache (clock speed doesnt really matter, but watch out over 750 as the board may not support it)
  Serial->Console adaptor (for console access)(you might also want an AGP video card to start with, to make sure the bios doesnt have any whacky settings - but be warned, the pix WONT boot with a video card inserted.

• 
  Pix OS (obtainable from CCO, or your nearest Cisco warez monkey)
  
  Pix Boothelper (Ditto)

• 
  Using dd (on Unix or workalike):
  • 
    dd if=bh61.bin of=/dev/fd0a (/dev/fd0 on Linux)
  
  Using ntrw.exe (on Windows):
  • 
    ntrw bh61.bin A:

• 
  pixboothelper>

• 
  address ip-address (ie "address", followed by the IP address of the inside interface (same subnet as tftp server)
  
  server tftp-ip-address (ie "server", followed up the IP address of the tftp server)
  file pix-os-filename (ie "file", follwed by the Pix OS filename (eg pix622.bin))
  
  then type:tftp
  
  and hit enter to begin the transfer.

• Intel SE440BX-2 motherboard
• 
  2 - 4 Intel 82557/82558/82559 Intel NICs (Dime a dozen)
  Cisco 16MB PIX Flash card (most expensive bit and the hardest to source)
  Floppy drive
  Case/power supply
  128MB PC100 SDRAM
  350MHZ Processor w/ 512K cache (clock speed doesnt really matter, but watch out over 750 as the board may not support it)
  Serial->Console adaptor (for console access)(you might also want an AGP video card to start with, to make sure the bios doesnt have any whacky settings - but be warned, the pix WONT boot with a video card inserted.

• 
  Pix OS (obtainable from CCO, or your nearest Cisco warez monkey)
  
  Pix Boothelper (Ditto)

• 
  Using dd (on Unix or workalike):
  • 
    dd if=bh61.bin of=/dev/fd0a (/dev/fd0 on Linux)
  
  Using ntrw.exe (on Windows):
  • 
    ntrw bh61.bin A:

• 
  pixboothelper>

• 
  address ip-address (ie "address", followed by the IP address of the inside interface (same subnet as tftp server)
  
  server tftp-ip-address (ie "server", followed up the IP address of the tftp server)
  file pix-os-filename (ie "file", follwed by the Pix OS filename (eg pix622.bin))
  
  then type:tftp
  
  and hit enter to begin the transfer.

So where does one find this IPSEC?

Here.

It died a long time ago, if you ask me! Hey, were's the graphical install on FreeBSD? Oh yeah, there isn't one! Welcome to 1980!

The eighties are still alive, and OpenBSD has a graphical install

Soft Updates ensure that the filesystem is always in a consistent state. Updates are effectively not marked as complete until they have actually all gotten to disk. This ensures that after a re-boot, the system is consistent, maybe with the disk state as that of a some seconds earlier. The Soft Updates technique is also much faster than journalling, which is your other option (reiserfs, ext3fs etc in Linux).

I said above that fscking is practically eliminated - in fact a fsck task still needs to run to recover sectors that are 'dirty' but the system is stable without it - critically the system boots up without it, and in the background at some point when the system finds time to do so it recovers the sectors marked 'dirty'; the soft update people call this a "background fsck".

Note that this won't stop loss of data - but then nothing will stop loss of data. fsck certainly won't even if it is run properly, because that's not what it does. What it does do is ensure the filesystem metadata is always consistent (i.e. whether a file has been created/deleted, contents of directories etc).

More details on soft updates can be found in the OpenBSD FAQ and also in the FreeBSD handbookFreeBSD handbook.

If you want to get the same kind of disk flushing that you get with DOS, then you can only really do that with a single-tasking operating system (if that's not a contradiction in terms!) which can therefore ensure a minimum of delay between the application generating data and it being flushed to disk. Note this is never perfect, but can be close enough that you'd only notice one in a million power-offs.

I posted this in some other discussion the other day but.........

Why not just use IPSec? My co worker and I have been trying to figure out how to securely deploy 802.11b around the office and I came up with the idea of using IPSec. I'm the lone Macintosh island in a sea of Windows desktops and laptops at the office so I'm waiting for next week(when I get my copy of Jaguar and hence IPSec support) to really get to hack on this but the current plan is use an IPSec VPN(and throw WEP out the f'ing window) to secure the line of communication. I will set up either an OpenBSD, FreeBSD or Linux(preference in that order, yeah I know I've got a BSD partiality) firewall between the AP and the wired LAN and only allow traffic over the IPSec VPN. From my initial research I found some docs on doing wired IPSec communication but in theory that should apply to the wireless as well.

here's some useful links. I hope to be able to adapt some of the information to suit using OS X.
OpenBSD IPSec
FreeBSD IPSec
Windows 2000 to FreeBSD
DaemonNews Article
FreebsdDiary Article

After pondering the "secureness" of using IPSec in lieu of WEP I've come up with one weakness and one side affect since clients get DHCP addresses in the clear and any communication to the wired LAN is encrypted. Say jane sales chick shows up with her personal laptop and tries to use the wireless network in the office she gets a IP address but can't get into the wired net because she can't establish a IPSec VPN. Joe cust service has his laptop in the office too. he get an IP but gets blocked by the IPSec Firewall. as a side affect there is nothing stopping Joe and Jane from swapping music, warez or pr0n. The only weakness I can think of is that Johnny hacker could try to exploit one of the wireless clients(if there are any) and use that as a jumping off point to the LAN or to his/her credentials. Another thing I've given some thought to is depending on the overhead of IPSec you could take the onion skin approach making the side effect a little more difficult to non tech type(we all know how secure WEP is) by also using 64 or 128 bit wep in addition to IPSec.

Since this is all theory until next week when I get Jaguar, feel free to point out any stupid lines off thought, inaccuracies, etc. I've got going on here. If I'm successful I'll probably document it and post on the Web.

It was never dropped, it never existed. The rumors that you heard were from columnists, and the occasional person from Apple who thought it would be a cool academic exercise.

OTOH, if you don't like how fragmented Linux is, give BSD a shot. http://www.freebsd.org, http://www.openbsd.org, or http://www.netbsd.org. I personnaly use OpenBSD, and a bit of FreeBSD. But to each his own. Enjoy!

his suggestion? mg - it's apparently "like emacs" except "without the bloat".

... of course i'm still going to keep using vim...

IPSec is really the big thing that got me excited about 10.2(and Windows network browsing and Quartz Extreme and CUPS and PAM blah blah.) My co worker and I were trying to figure out how to securely deploy 802.11b. I'm waiting for next week to really get to hack on this but the current plan is use an IPSec VPN(and throw WEP out the f'ing window) to secure the line of communication. I will set up either an OpenBSD, FreeBSD or Linux(preference in that order, yeah I know I've got a BSD partiality) firewall and only allow traffic over the IPSec VPN. From my inital research I found some docs on doing hardwired IPSec communication but in theory that should apply to the wireless as well.

here's some useful links. I hope to be able to adapt some of the information to suit using OS X.
OpenBSD IPSec
FreeBSD IPSec
Windows 2000 to FreeBSD
DaemonNews Article
FreebsdDiary Article

After pondering the "secureness" of using IPSec in lieu of WEP I've come up with one weakness and one side affect since clients get DHCP addresses in the clear and any communication to the wired LAN is encrypted. Say jane sales chick shows up with her personal laptop and tries to use the wireless network in the office she gets a IP address but can get into the wired net because she can't esablish a IPSec VPN. Joe cust service has his laptop in the office too. he get an IP but gets blocked by the IPSec Firewall. as a side affect there is nothing stopping Joe and Jane from swapping music, warez or pr0n. The only weakness I can think of is that Johnny hacker could try to exploit one of the wireless clients(if there are any) and use that as a jumping off point to the LAN or to his credentials. Another thing I've given some thought to is depending on the overhead of IPSec you could take the onion skin approach making the side effect a little more difficult to non tech type(we all know how secure WEP is) by also using 64 or 128 bit wep in addition to IPSec.

Since this is all theory until next week when I get Jaguar. Feel free to point out any stupid lines off thought I've got going on here. If I'm successful I'll probably document it and post on the Web.
--

I've tried compiling MySQL version 4.0.2 on OpenBSD.

First of all, to even get this thing compiled, you'll probably need to apply patches from the ports. See http://www.openbsd.org/cgi-bin/cvsweb/ports/databa ses/mysql/patches/ for OpenBSD ports patches.

For example, I've needed patch-innobase_include_univ_i to compile any recent MySQL to compile on OpenBSD 3.1.
That patch is quite funny:

#define UNIV_INLINE __inline
#else
/* config.h contains the right def for 'inline' for the current compiler */
-#if (__GNUC__ == 2)
-#define UNIV_INLINE extern inline
-#else
-/* extern inline doesn't work with gcc 3.0.2 */
+/* mysql people don't understand extern inline */
#define UNIV_INLINE static inline

When installing MySQL 4.0.2 I've applied all of those patches, and then configured, compiled and made make install.

The database new MySQL daemon started up and operated fine (with previous version's data files), but mysql 4 client were unable to connect (I've got an "ERROR:" error message. Tells much, doesn't it?).

So, to summarize, wait some more time, at least until they release a beta.

And it looks like they're not "eating their own dog food," and eating Sun dog food instead

did you ever think there might a reason for that?

then you can't trust a web server to give you a web page with an unaltered MD5 sum. Surely this is common sense?

I am not sure, but this just might be the reason why systems like BSD ports and Gentoo portage store the MD5 sums in the ports trees, and don't in fact get them from websites.

The real solution is digital signatures (i.e. an MD5 sum encrypted with a private key).

WOW! what an original and fresh solution! you sir, are some sort of genious for coming up with this.

congratulations, you've managed to regurgitate several of the things that have been said, literally, hundreds of times today already. I think the Society for Prevention of Cruelty to Dead Horses might have a bone to pick with you.

• It differs from a "clean" openssh package by one line in the Makefile and an additional sourcefile.
• The sourcefile is very cryptic and if you wouldn't know you'd think it's just an ssh source file like any other.
• The suspicious line in the Makefile compiles the sourcefile, executes it. This binary itself writes out some shellscript, which in turn generates another C source file, which gets compiled and executed.
• The additional line in the Makefile and the additional source file are deleted.
• This last binary opens up a socket to some server and, depending on the input it gets from the socket, exits, respawns or opens a shell (/bin/sh).

So the backdoor is in the Makefile, not the OpenSSH software itself.

One thing to mention is that IMHO this is not a fault of OpenBSD. As anyone can read in their FAQ www.openbsd.org (and ftp.openbsd.org) is run on Solaris.

pony up the money, cowboy.

It's simple. Pirates are very determined to continue piracy. If the MPAA, RIAA, or whoever start hacking, three things will happen.

1. The outcome will be true to the traditional form of computer security: the more people you have banging on something, the better it'll get in the long run. People who design and develop the P2P networks and the systems they run on will have intense motivation to make those systems more secure against crackers. More bugs will be found and squashed since the attackers in this case are not afraid of legal ramifications.

2. Pirates'll change their software. Most pirates are probably on fairly insecure systems at the moment. When they find themselves being shut down in this manner, they'll move to more secure platforms and services.

3. Whoever these entities are will eventually blunder such that they will destroy both their credibility and make them look like jackasses. In time, they are going to hire people who will abuse this to the maximum possible extent. There's also the extreme likelihood that some attacks will be waged on critical systems for businesses or whoever (someone sets of a warez depot on their company's xyz server).

These people who want this nonsense fail to realize exactly how pointless all this is. They don't understand that they are dealing with an animal that heals faster than it can be injured. When they took out Napster, a dozen file sharing services popped up to take its place. Likewise today, when they start cracking to take down sharing networks and systems, the users will only build them up stronger. Not to mention that no matter at what scale they launch these attacks, the MPAA, RIAA, or whoever could never have enough attackers to even make a dent on the whole system. There's at least an order of magnitude more pirates than there are people stopping them. Again, they will make themselves look like jackasses.

Damn fools. Greed makes them both blind and stupid. They could spend some time coming up with a fair business model that could survive out there today without a lot of extra bullshit (Palladium, DRM, etc). That would require a lot less time and money.

OpenBSD not only has more security, but you can leave it out for longer without having to remotely upgrade. Ever remotely patched/installed a kernel? It's quite, quite annoying. Why is it you can do this? Less holes AND more highly integrated code... plus, once you add in that the memory allocation routines in OpenBSD are quite extraordinary (try running X at a high resolution in linux, then run the exact same thing in openbsd... you'll see the difference in magnitudes ^_^), so its harder to overload your memory. Just a thought.

But on the other hand, you know what idealism is ...

• PuTTY is an SSH1+SSH2 implementation. PSCP, an scp-style program for Windows, is also available.

  PuTTY is available under the MIT licence (BSD-like).

  "PuTTY is a free implementation of Telnet and SSH for Win32 platforms, written and maintained primarily by Simon Tatham, who lives in Great Britain."

• TTSSH (SSH1) is an SSH1-only implementation, by Robert O'Callahan.

  "TTSSH is a free SSH client for Windows. It is implemented as an extension DLL for Teraterm Pro. Teraterm Pro is a superb free terminal emulator/telnet client for Windows, and its source is available. TTSSH adds SSH capabilities to Teraterm Pro without sacrificing any of Teraterm's existing functionality. TTSSH is also free to download and use and its source is available too, with an open source license. Furthermore, TTSSH has been developed entirely in Australia [...]."

• Cygwin (POSIX software on top of Windows)

  OpenSSH (SSH1 and SSH2 protocol) with Cygwin can run on Windows using the portable version of OpenSSH.

• MSSH

  MSSH from the Metropolitan State College of Denver supports Windows 95 and Windows 98, supporting SSH1 protocol.

• OpenSSH for Windows

  Another OpenSSH running on top of Windows..

• Secure iXplorer

  Secure iXplorer is graphical front end to PuTTY's pscp.exe.

• WinSCP

  WinSCP is a scp(1) program for Windows, with PuTTY integrated into it.

• NiftyTelnet 1.1 SSH is an SSH1-only implementation which comes with a scp-style program. Written by Jonas Wallden.

  "NiftyTelnet 1.1 SSH r3 is an enhanced version of Chris Newman's NiftyTelnet 1.1 application which adds support for encrypted terminal sessions using the SSH (Secure Shell) protocol. Please read the included Readme file before distributing this version."

• MacSSH is an SSH2-only implementation.

  "MacSSH is a modified version of BetterTelnet with SSH2 support. [...] The only SSH2 client for MacOS that I could find is a commercial product thats costs more than $100, and it crashes my Mac when closing a session... Since it's best to do things by oneself, here's MacSSH."

• PuTTY is an SSH1+SSH2 implementation. PSCP, an scp-style program for Windows, is also available.

  PuTTY is available under the MIT licence (BSD-like).

  "PuTTY is a free implementation of Telnet and SSH for Win32 platforms, written and maintained primarily by Simon Tatham, who lives in Great Britain."

• TTSSH (SSH1) is an SSH1-only implementation, by Robert O'Callahan.

  "TTSSH is a free SSH client for Windows. It is implemented as an extension DLL for Teraterm Pro. Teraterm Pro is a superb free terminal emulator/telnet client for Windows, and its source is available. TTSSH adds SSH capabilities to Teraterm Pro without sacrificing any of Teraterm's existing functionality. TTSSH is also free to download and use and its source is available too, with an open source license. Furthermore, TTSSH has been developed entirely in Australia [...]."

• Cygwin (POSIX software on top of Windows)

  OpenSSH (SSH1 and SSH2 protocol) with Cygwin can run on Windows using the portable version of OpenSSH.

• MSSH

  MSSH from the Metropolitan State College of Denver supports Windows 95 and Windows 98, supporting SSH1 protocol.

• OpenSSH for Windows

  Another OpenSSH running on top of Windows..

• Secure iXplorer

  Secure iXplorer is graphical front end to PuTTY's pscp.exe.

• WinSCP

  WinSCP is a scp(1) program for Windows, with PuTTY integrated into it.

• NiftyTelnet 1.1 SSH is an SSH1-only implementation which comes with a scp-style program. Written by Jonas Wallden.

  "NiftyTelnet 1.1 SSH r3 is an enhanced version of Chris Newman's NiftyTelnet 1.1 application which adds support for encrypted terminal sessions using the SSH (Secure Shell) protocol. Please read the included Readme file before distributing this version."

• MacSSH is an SSH2-only implementation.

  "MacSSH is a modified version of BetterTelnet with SSH2 support. [...] The only SSH2 client for MacOS that I could find is a commercial product thats costs more than $100, and it crashes my Mac when closing a session... Since it's best to do things by oneself, here's MacSSH."

Mandated by whom? Last time I checked there were several major non-Win OSes out there. Do you really think hardware vendors are SO STUPID as to cripple them all in the processor? Or to allow Congress to require same without a very hard fight?

Darren Reed also asked in the OpenBSD misc mailing list
for prior art and points to pf probably being affected,
too (read here).

Daniel Hartmeier, swiss Author of PF, the OpenBSD packet
filter, has a good reply finding prior art and Darren even thanks him explicitly a lot, which is not what we _were_ used to read from him.

I personally do not have any objections against him,
still - though I use pf as it is in OpenBSD - the operating system of my choice, and not
even the recent OpenSSH bug could prevent me from
trusting that team.