OpenBSD has been a solid firewall, router, bridge, MX, DNS server, NIS, NFS, Web, SSH/SCP/SFTP machine
with nary a GUI to be seen.
(emphasis mine)
Some would count the lack of a GUI as a downside. Don't knock GUIs -- even web-based ones. They can really help out with the easy stuff. And since it's a Unix, you can always pop up a shell window to do the more complicated stuff.
It's most likely because adding IPSEC adds your build time. Also, few people use it.
A problem with KAME IPSEC (and, I think, pretty much every non-free/swan IPSEC implementation) is that they don't do opportunistic encryption. You need pre-arranged certs or shared keys. If it did have something like that, I bet more people would use IPSEC by default.
(Annoying problem if people do start doing that: tcpdump becomes pretty much useless as a diagnostics tool.)
Last night I thought about that, and came up with a couple of ways to do it. I need some time to test them out...
I wrote a wrapper for nistp224 in python; that'll take care of the auth/key exchange issue (elliptic curve keys are
faster to compute and smaller than RSA/etc keys). I picked python because there already are a few python-based IM clients. Plus I wanted to figure out how to extend python.
A lot of this depends on what the remote user has access to. If you've got gaim on the user end, you can write your auth/encryption code as a perl plugin on both ends, and you're set.
You (the remote user) open a chat window with the gaim running on the server. You type:/auth [ your perl plugin and the remote plugin talk to each other and agree on session keys and whatnot ] Remote: go ahead. You type: [commands to execute] Remote: [responses] You type:/end Remote: see ya.
If the user has access to a web browser with Java 1.0 support, then the gaim plugin or whatever can trivially use s/key or opie to authenticate the user (there are many s/key or opie java applets out there). Similarly, the session can be encrypted (though you'd have to write the applet for that yourself). You'd write your command in one pane, hit a button, the applet will place the encrypted text in the other pane. You paste the encrypted text into your AIM client. When it responds, you paste the encrypted text into the applet, hit a button, and read the response.
This fails in one area -- you can't run commands that read directly from/dev/tty (examples: sudo, passwd, etc).
I'm speculating here, but maybe the poster wants to access servers behind some corporate firewall that allows IM clients but not remote access via ssh.
The one thing pretty much all the factions -- mainstream or 'dangerous' -- agree upon is that Muhammad didn't create the religion. That is, after all, one of the 'doctrines', as you put it.
Now, technically, this test.exe (which is, in reality, a binary of sorts) should run on Windows as well, as long as you have the.Net infrastructure in place.
> Would you really want to try to repair a broken system without ls?
I've had to -- echo * works well enough, sometimes. Some Linux install disks give you a shell, but few utilities other than mount, mknod, cat, etc. Now, if they gave us ed I wouldn't have to "cat >>/mnt/etc/fstab" and the like.
If you search the FreeBSD freebsd-hackers mailing list, you'll even find a "more" command implemented with shell builtins (at least, I don't remember it using cat). It's too long to remember, though.
Finder may be proprietary, but you can run Darwin, NetBSD or Linux on most of the macs. Thanks to USB (and Darwin), you can even use most of the same peripherals.
The announcment of the license thingy with Sun came out 12/01 and I haven't heard anything yet.
Yeah, what's up with that? It really bites -- I know people who've switched from running FreeBSD to Linux just for the Java support on their servers.
While there is a native unofficial 1.3 port, I've heard a friend (professional Java developer) run into a few random problems that he couldn't reproduce on the Linux 1.3 JDK. Then again, knowing Java, it's probably another one of those "Write One, Test Everywhere" issues.
Another issue with FreeBSD is its weak threading support. A lot better in -current, but there won't be a release of -current for a month or so (and even then, it'll take a 5.1 release before people start using it in anger).
Re:What is the relevance of FreeBSD today?
on
FreeBSD 4.7-RELEASE
·
· Score: 1
The problem with this is that you need to switch distributions to use that feature. That's a major downside -- you almost always have to give up a few features of your favorite distribution to use a new one. You also risk becoming incompatible with the rest of the "Linux world", which is an issue when trying to run 3rd-party apps that only available in.rpm or.deb format.
(I wonder if anyone's compared the number of.rpms out there with the number of.debs, or whatever the second most famous packaging format is).
I don't know of any Windows tools that will make it directly authenticate via ldap. However, if you run Samba, you can have it store its passwords in ldap. That'll give you unified passwords on the Windows and Unix machines.
Yeah, lets all use abstract data types that default as real numbers or dynamically allocated type changers so that all our math ops take 4 times longer or more to compute even when the.0-> precision isn't needed.
Well, that's the thing with C. With some other languages, you get compilers that figure out this stuff as early as possible (programmer hints in the code help), and will optimize code down to C-speed levels (or close enough). You don't have that option with C -- you figure out if you need ints, long ints, or whatever -- and you're stuck with that choice.
It is possible to write compilers for non-C languages in non-C languages, and still get performance similar or equal that of C. Yes, you can always write something up in C and tweak it such that it's the fastest code around, but if some languages give you (say) 90% of the efficiency of C with less than 20% of the effort, why would you bother with C? Non-C languages generally have some limitations that make them unsuitable for use in all areas where C's used. For example, their implementations might have large runtimes, or they might not have bindings for some external app (graphical toolkit, database, etc). These are valid reasons to use C. Now that you'll find socket and/or web interfaces in most libraries for non-C languages, though, that's not as big an issue as it once was. Examples of really fast/high quality compilers for non-C languages written in their own language: cmucl (Common Lisp), fun-o's dylan compiler (Dylan), standard ml of new jersey (ML).
Literally decades before C dev systems got graphical debuggers and incremental compilation, other languages had those features.
There are languages out there that'll take two integers and return 1/2 for that operation. Perhaps that's what the poster was after. In fact, with them it doesn't matter if you try to divide 1 by 2, or 10000000000 by 2000000000 -- they'll happily accept large numbers and treat them properly. Both 1 and 10000000000 are integers, it's just that C's 'int' and 'long' types are somewhat limited. But that's C for ya.
The fun thing about Lisp (Common Lisp, that is) is that you're not limited to using functional programming constructs. You can also write code in imperative style, or OOP. It's not a pure functional language like, say, Haskell. SQL, by the way, is sometimes classified as a near-fp language.
I don't know about Solaris 9, but Solaris 8 ran just fine on my dual-processor usparc box at work. I believe its license limits it to systems with fewer than eight processors.
I believe Sun released NFS v4's source code, but that's a relatively recent event. What Sun did release was ONC RPC; you could download and build portmap/rpcgen/etc for your OS. It's a necessary precursor to running NFS.
Note that while the i386 port just got SMP support, other ports have had it for a while. NetBSD/macppc got it in August, NetBSD/sparc got it over a year ago, etc.
Slashdot Mirror
(emphasis mine)
Some would count the lack of a GUI as a downside. Don't knock GUIs -- even web-based ones. They can really help out with the easy stuff. And since it's a Unix, you can always pop up a shell window to do the more complicated stuff.
Check out Mac OS X for an example of this.
It's most likely because adding IPSEC adds your build time. Also, few people use it.
A problem with KAME IPSEC (and, I think, pretty much every non-free/swan IPSEC implementation) is that they don't do opportunistic encryption. You need pre-arranged certs or shared keys. If it did have something like that, I bet more people would use IPSEC by default.
(Annoying problem if people do start doing that: tcpdump becomes pretty much useless as a diagnostics tool.)
Last night I thought about that, and came up with a couple of ways to do it. I need some time to test them out...
I wrote a wrapper for nistp224 in python; that'll take care of the auth/key exchange issue (elliptic curve keys are faster to compute and smaller than RSA/etc keys). I picked python because there already are a few python-based IM clients. Plus I wanted to figure out how to extend python.
A lot of this depends on what the remote user has access to. If you've got gaim on the user end, you can write your auth/encryption
/auth /end
/dev/tty (examples: sudo, passwd, etc).
code as a perl plugin on both ends, and you're set.
You (the remote user) open a chat window with the gaim running on the server.
You type:
[ your perl plugin and the remote plugin talk to each other and agree on session keys and whatnot ]
Remote: go ahead.
You type: [commands to execute]
Remote: [responses]
You type:
Remote: see ya.
If the user has access to a web browser with Java 1.0 support, then the gaim plugin or whatever can trivially use s/key or opie to authenticate the user (there are many s/key or opie java applets out there). Similarly, the session can be encrypted (though you'd have to write the applet for that yourself). You'd write your command in one pane, hit a button, the applet will place the encrypted text in the other pane. You paste the encrypted text into your AIM client. When it responds, you paste the encrypted text into the applet, hit a button, and read the response.
This fails in one area -- you can't run commands that read directly from
I'm speculating here, but maybe the poster wants to access servers behind some corporate firewall that allows IM clients but not remote access via ssh.
> Given current events, are you really sure that you prefer the mainstream Islamic doctrine?
What current events are the result of mainstream Islamic doctrine?
The one thing pretty much all the factions -- mainstream or 'dangerous' -- agree upon is that Muhammad didn't create the religion. That is, after all, one of the 'doctrines', as you put it.
Using Mono, I compiled this:
.Net infrastructure in place.
class test {
static int Main(string[] args) {
return 42;
}
}
I got:
% mcs test.cs
[00:000] - FindMembers timer (used 0 times)
[00:003] - TypeContainer.FindMembers timer (used 23 times)
[00:014] - MemberLookup timer (used 2 times)
[00:000] - CachedLookup timer (used 1 times)
[00:031] - Cache init (used 2 times)
[00:001] - Misc timer (used 1 times)
0 - Find members
2 - Member cache
0 - Misc counter
Compilation succeeded
% ls -l test.exe
-rw-r--r-- 1 fn wheel 2048 Oct 20 00:07 test.exe
% mint test.exe
% echo $?
42
%
Now, technically, this test.exe (which is, in reality, a binary of sorts) should run on Windows as well, as long as you have the
> Would you really want to try to repair a broken system without ls?
I've had to -- echo * works well enough, sometimes. Some Linux install disks give you a shell, but few utilities other than mount, mknod, cat, etc. Now, if they gave us ed I wouldn't have to "cat >> /mnt/etc/fstab" and the like.
If you search the FreeBSD freebsd-hackers mailing list, you'll even find a "more" command implemented with shell builtins (at least, I don't remember it using cat). It's too long to remember, though.
Finder may be proprietary, but you can run Darwin, NetBSD or Linux on most of the macs. Thanks to USB (and Darwin), you can even use most of the same peripherals.
I haven't tried 4.2.1, but XFree86 from CVS didn't support my new GeForce 4 Ti 4200 about two months ago.
Supposedly the official Nvidia binary driver for FreeBSD is almost ready for release.
Er, write onCe, test everywhere.
FreeBSD boots fine with grub. FreeBSD also comes with its own bootloader; I believe that'll work with Linux (with root on ext2fs).
I have a dual-boot system with FreeBSD -current and Debian Sarge; I have to use grub because my Sarge installation is on XFS.
Yeah, what's up with that? It really bites -- I know people who've switched from running FreeBSD to Linux just for the Java support on their servers.
While there is a native unofficial 1.3 port, I've heard a friend (professional Java developer) run into a few random problems that he couldn't reproduce on the Linux 1.3 JDK. Then again, knowing Java, it's probably another one of those "Write One, Test Everywhere" issues.
Another issue with FreeBSD is its weak threading support. A lot better in -current, but there won't be a release of -current for a month or so (and even then, it'll take a 5.1 release before people start using it in anger).
The problem with this is that you need to switch distributions to use that feature. That's a major downside -- you almost always have to give up a few features of your favorite distribution to use a new one. You also risk becoming incompatible with the rest of the "Linux world", which is an issue when trying to run 3rd-party apps that only available in .rpm or .deb format.
.rpms out there with the number of .debs, or whatever the second most famous packaging format is).
(I wonder if anyone's compared the number of
Faried.
I don't know of any Windows tools that will make it directly authenticate via ldap. However, if you run Samba, you can have it store its passwords in ldap. That'll give you unified passwords on the Windows and Unix machines.
VMS...I don't know.
Well, that's the thing with C. With some other languages, you get compilers that figure out this stuff as early as possible (programmer hints in the code help), and will optimize code down to C-speed levels (or close enough). You don't have that option with C -- you figure out if you need ints, long ints, or whatever -- and you're stuck with that choice.
It is possible to write compilers for non-C languages in non-C languages, and still get performance similar or equal that of C. Yes, you can always write something up in C and tweak it such that it's the fastest code around, but if some languages give you (say) 90% of the efficiency of C with less than 20% of the effort, why would you bother with C?
Non-C languages generally have some limitations that make them unsuitable for use in all areas where C's used. For example, their implementations might have large runtimes, or they might not have bindings for some external app (graphical toolkit, database, etc). These are valid reasons to use C. Now that you'll find socket and/or web interfaces in most libraries for non-C languages, though, that's not as big an issue as it once was.
Examples of really fast/high quality compilers for non-C languages written in their own language: cmucl (Common Lisp), fun-o's dylan compiler (Dylan), standard ml of new jersey (ML).
Literally decades before C dev systems got graphical debuggers and incremental compilation, other languages had those features.
There are languages out there that'll take two integers and return 1/2 for that operation. Perhaps that's what the poster was after.
In fact, with them it doesn't matter if you try to divide 1 by 2, or 10000000000 by 2000000000 -- they'll happily accept large numbers and treat them properly.
Both 1 and 10000000000 are integers, it's just that C's 'int' and 'long' types are somewhat limited.
But that's C for ya.
The fun thing about Lisp (Common Lisp, that is) is that you're not limited to using functional programming constructs. You can also write code in imperative style, or OOP. It's not a pure functional language like, say, Haskell.
SQL, by the way, is sometimes classified as a near-fp language.
I don't know about Solaris 9, but Solaris 8 ran just fine on my dual-processor usparc box at work. I believe its license limits it to systems with fewer than eight processors.
I believe Sun released NFS v4's source code, but that's a relatively recent event.
What Sun did release was ONC RPC; you could download and build portmap/rpcgen/etc for your OS. It's a necessary precursor to running NFS.
I confess, while reading a long document/web site/whatever, I unconsciously play with my keyboard's nipples.
That won't work with this keyboard...
Note that while the i386 port just got SMP support, other ports have had it for a while. NetBSD/macppc got it in August, NetBSD/sparc got it over a year ago, etc.
Actually, many embedded system developers use NetBSD for their eval boards and such.
Also, at least one major company has used NetBSD in the past -- DEC, for their DNARD ("shark") systems.
It's actually a non-standard POP protocol extension -- which pretty much everyone supports. The syntax is
top
If num-lines is 0, you get just the header.