Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Announcements Operating Systems BSD

NetBSD 1.6 Released 206

Posted by timothy from the what-only-39-supported-platforms dept.
BSD Forums writes "The NetBSD Project is pleased to announce that release 1.6 of the NetBSD operating system is now available. NetBSD is widely known as the most portable operating system in the world. It currently supports fifty two different system architectures, all from a single source tree, and is always being ported to more. The NetBSD 1.6 release contains complete binary releases for thirty nine different system architectures. The thirteen remaining are not fully supported at this time and are thus not part of the binary distribution." hubertf adds some important notes: "Many of the FTP Mirrors are now carrying the NetBSD 1.6 distribution. Please try to use the NetBSD FTP Mirror Site closest to you. ... Czech, German, French, Japanese, Polish, Portugese , Russian, Spanish and Swedish language translations of the NetBSD 1.6 release announcement are available." The NetBSD packages collection now includes over 3000 pieces of software, including KDE3, OpenOffice and many more of the usual suspects.
This discussion has been archived. No new comments can be posted.

NetBSD 1.6 Released More

NetBSD 1.6 Released

Comments Filter:
  • How does NetBSD relate to Linux?
  • Man, I was about to make a post (to the NetBSD foundation board election results story) wondering if 1.6 would make the front page or not... I guess it did, which is nice for a change.

    • Re:Front page? (Score:1, Flamebait)

      by cscx ( 541332 )
      Yeah, just look at these major changes:

      Changelog for sysctl(8):

      * sysctl.c: changed ++j to j++ [Brian Pane]

      * sysctl.c: changed ++i to ++joe in honor of myself [Joe Orton]

      * sysctl.c: fuck you guys, ++i is better [Justin Erenkrantz]

      * sysctl.c: changed i += 1 to i++ for better performance [Graham Leggett]

      * sysctl.c: changed i = i + 1 to i += 1 [Ian Holsman]

  • I r dumb :-/ (Score:2, Interesting)

    by Zakabog ( 603757 )
    I was just wondering, what's the difference between OpenBSD, FreeBSD and NetBSD? I have FreeBSD on one computer (just wanted to learn a new OS and I already have linux on a bunch of my computers). When I picked which BSD I wanted I just figured I'd go with FreeBSD since I hear about it alot. Now I'm beginning to wonder, what's the difference (really, I don't have a clue.) Sorry that this is a bit off topic I just don't want to be kicked from some #bsd channels for asking such a stupid question.
    • Well, you already run freebsd, so you know what that's like. OpenBSD focuses on being secure. ("One remote hole in the default install, in nearly 6 years!") NetBSD is famous for being so portable ("Of course it runs NetBSD.") FreeBSD's tagline is "The power to serve," so I guess it makes a good server OS. Personally I tend to think of FreeBSD as focusing on x86, and having an outstanding ports collection.

    • Here are the differences... (Score:4, Interesting)

      by Cadre ( 11051 ) on Saturday September 14, 2002 @10:33AM (#4256815) Homepage
      I was just wondering, what's the difference between OpenBSD, FreeBSD and NetBSD?

      TedU recently posted in comp.unix.bsd.openbsd.misc [google.com] the answer to this question:

      "What's the difference?" doesn't count as a specific question.


      FreeBSD has tcsh installed as /bin/csh. OpenBSD and NetBSD don't. NetBSD runs on a Cobalt Qube2. OpenBSD and FreeBSD don't. OpenBSD can encrypt swap. NetBSD and FreeBSD don't.

      I hope that explains the differences you were interested in.
    • The differences are a lot less significant than they used to be.

      FreeBSD was originally designed to be the most feature rich, but limited to x86 architecture.

      OpenBSD was designed to be the most secure, but with less features.

      NetBSD was designed to run on every obscure architecture you can think of (dreamcasts, javastations, blenders)

      Nowadays though, it means less and less.

      OpenBSD is still by default the most secure, but if you know what you're doing any of the three is very secure.

      FreeBSD still has the most ports, but binary compatiblity is now more or less a reality amongst them (and they can run 99% of Linux apps as well).

      NetBSD still works on the most platforms, but even FreeBSD (with its 386BSD roots) works (or soon will) on most common platforms.

      I personally use FreeBSD for servers (more options) and NetBSD for clients (easier to configure).

    • I was just wondering, what's the difference between OpenBSD, FreeBSD and NetBSD?

      Why is this question posted every time a BSD story makes it to the front page? Inquiring minds want to know...
    • OpenBSD is for a secure gateway.

      NetBSD is for an easy(for Unix) to configure desktop.

      FreeBSD is for a powerful server.

      MacOSX is if you want all of these things, and still want to run apps you can buy in a store or ones you may actually have heard of. If you need to run Office(the real one), Photoshop, Dreamweaver, the list goes on, and still use all the Linux and BSD software you want to run. Hope that clears it up:-)

    • No, you're not dumb. Just curious. Curious is a Good Thing.

      Although all the *BSD's are based on the same branch of the Unix tree (Berkeley Systems Design, as you may already know), the difference between NetBSD, OpenBSD, and FreeBSD is, at least to my eyes, in the orientation of the particular system involved.

      To clarify: NetBSD's orientation has always been to be runnable on as many different hardware architectures as possible, and to be a solid, general-purpose OS for servers and development. So, if your goal is to set up a free *nix OS on, say, a MicroVAX or older NEC RISC machine, NetBSD would be a good choice.

      FreeBSD has always been oriented towards the PC platform, hardware-wise, and also seems to be among the more user-friendly of the BSD family. If you're just starting out with BSD, and you don't want to learn the ins and outs of non-PC hardware, FreeBSD is a good choice that will grow with you as you gain (programming) skills.

      OpenBSD has always had one, single, simple focus: Security. Its aim is to be secure right out of the box. Default installations are locked down tight, port and service-wise, until you actually go in and enable what you want to enable. OpenBSD's other strength is that it is rapidly gaining on NetBSD where being able to run on many different hardware platforms is concerned.

      If you're setting up a machine to be a firewall/router, or a -very- secure server, OpenBSD will do the trick.

      Hope that helps. Keep the peace(es).

      • 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 [netbsd.org], but OpenBSD has mvme88k [openbsd.org]. 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. :)

  • Ignorant question (Score:1, Interesting)

    by Anonymous Coward
    OK, I could Google for this, but could someone with wisdom enlighten me with a summary or some well chosen links ...

    How does NetBSD compare with Linux in terms of:

    • Everyday use - ie command line syntax, configuration...
    • What it's good for - in particular, is it good for desktop use(since it runs KDE)?
    • Advantages and disadvantages
    • Everyday use - ie command line syntax, configuration...

      similar enough not to matter. i mean, you get bash, grep, etc in both.



      What it's good for - in particular, is it good for desktop use(since it runs KDE)?

      it's a general purpose unixy os, like linux. good for the same stuff, including desktop foo.



      Advantages and disadvantages

      depend entirely on your requirements.



      i don't have any links. try them both out and decide for yourself.
    • As far as command line syntax - it's so similar you could go from linux to NetBSD for a look around the OS without blinking much - certainly less of a change than jumping from linux to say, a windows command prompt :).

      It's worth taking a peek at - I think that knowing two similar but different OS's fairly well is near as important as knowing one single one inside out.

      a grrl & her server [danamania.com]

      • As far as command line syntax - it's so similar you could go from linux to NetBSD for a look around the OS without blinking much - certainly less of a change than jumping from linux to say, a windows command prompt :).

        I hate to state the obvious, but what matters is your shell, not the OS. I managed to get bash (and the standard GNU console tools) on my Solaris, AIX, and IRIX accounts, and it's not easy to tell which one I'm on a lot of the time. That's why the hostname's in the prompt ;) But if I have to use ksh or csh I notice the difference pretty quickly, regardless of OS.

    • Re:Ignorant question (Score:1, Informative)

      by Anonymous Coward
      BSD flavours tend to use various GNU tools, and GNU/Linux distros similarly have a lot of BSD utilities, so the differences aren't large. If you install the Bash shell, you'll find a very familiar working environment, with just some differences in the filesystem layout and admin tasks that need to be studied.

      As for desktop use, it's probably not going to give you anything over Linux on a soopa-doopah Pentium 4 512M monster. NetBSD's goal is portability and simplicity -- a small, solid and useful OS for all sorts of different machines. All platform ports are built from the same tree, so NetBSD on your ancient Atari Falcon will behave virtually identically to it running on a goliath Sun box.

      Contrast this to Linux, where a lot of non-i386 ports tend to be maintained as patches from the main tree, and use different distros etc.

      Give NetBSD a whirl. It's not fancy but it's very reliable and easy to understand. You'll learn more about UNIX in general.

  • "Supported" systems (Score:5, Informative)

    by 00_NOP ( 559413 ) on Saturday September 14, 2002 @05:02AM (#4256123) Homepage
    Not wanting to start a religious war and all that... but although NetBSD lists the Dreamcast as supported. the support is pretty poor: no sound, no lightgun, no rumblepak, no mouse, no X windows, no vmu. All of these are supported in LinuxDC [sourceforge.net].

    • Re:"Supported" systems (Score:1, Insightful)

      by Anonymous Coward
      There's a reason for this; once NetBSD hackers learn how to boot, Linux developers are able to swoop in, look at the bootstrap code, and use it as documentation to port Linux in. A GPL developer can't become 'tainted' from a glance at BSD code, but most BSD developers would rather not tempt fate and the FSF.

      Thus, the support from Linux doesn't get rolled back into the pioneering system, and it languishes until the new discoveries are documented enough outside of source that some enterprising soul says, "Damn, Linux has had this support for years, and we still don't?," does a Google, finds the spec in human language, and submits their own implementation.

      This is not to lambaste either license, but to point out that the disparity is the root of the problem. Give props to NetBSD for getting you booting!
    • Not wanting to start a religious war and all that... but although NetBSD lists the Dreamcast as supported. the support is pretty poor: no sound, no lightgun, no rumblepak, no mouse, no X windows, no vmu. All of these are supported in LinuxDC

      Bear in mind, netbsd has a LOT fewer developers than linux. Also bear in mind that some people don't like the GPL, and therefore choose not to use linux.

      Don't get me wrong...I don't mind the GPL, and I use linux on some machines. I just prefer netbsd, and I'd rather run an X-Less, Mouse-Less NetBSD than a nice linux install. This is what most NetBSD users have in common: were crazy hardcore!

      • That's strange, I prefer a nice NetBSD install over a nice linux install. Much more reliable, has solid NFS code, and is generally more stable and doesn't suffer from odd glitches I've seen using linux on my main workstation. My other workstation, a laptop, runs NetBSD (only IrDA doesn't work), with a nice X interface, a couple of mice, and KDE and whatnot.

        Although I must agree: I'm odd. I choose BSD license over GPL. I choose NetBSD over linux. I choose innovation by a stable collection of hardcore developers over strange coders from all over the globe trying to get their code into an overhyped OS.
  • I've been sitting waiting for the FreeBSD Sparc port for way too long. Not this is not a Sparc-64 or UltraSparc. I have about a metric ton of SparcStation 5 machines that desperately need release from the old old version of NetBSD that runs on them. If 1.6 is good enough, it's quite possible I can release the anger I have over FreeBSD and not join the Dark Side. Whew.
    • i think you've been waiting for the wrong thing. right from the beginning, freebsd's sparc port effort has aimed for the sparc4u, not the older architectures.
    • NetBSD loves the Sparc 32-bit stuff (Except the SS1000 and SC2000). I'm currently running it at home on a SparcStation Voyager and am lookin forward to the PCMCIA + Sparc support in 1.6 (802.11 anyone?). At work i run it on a SparcStation 20 with a 150mhz HyperSPARC. Its mainly used for testing scsi gear and SBus cards. About my only bitch is that it doesn't support the sound in either of them. Appearantly Sun used an audio chip for the audio AND the onboard ISDN in both of these machines (a la windodem). Oh yeah, i'm also running it on my laptop but am considering switching it back to linux for better wardriving^W802.11 support :)
    • OpenBSD has been running on Sparcstations for years...works fine, installs easily enough. Try it!
  • It runs on Playstation 2 and Dreamcast... when will it run on the X-Box? (:

    Oh ya, and can you make a beowulf cluster of NetBSD boxes?

    • Re:Ponderances (Score:2, Interesting)

      by GigsVT ( 208848 )
      You can technically make a beowulf cluster out of anything that supports openssh that you can compile the pieces of your program for.

      A simple beowulf cluster is just a shell script that does some sshing to each client and compiling and running the job to be run, combine that with another trivial script to scp files over, and that's it.

      clusterrun.sh:
      ssh cluster@192.168.0.1 $1
      ssh cluster@192.168.0.2 $1 ...
      ssh cluster@192.168.0.n $1

      clustercopy.sh
      scp $1 cluster@192.168.0.1:$2
      scp $1 cluster@192.168.0.2:$2 ...
      scp $1 cluster@192.168.0.n:$2

      $ ./clustercopy.sh mysource.c '/home/cluster/work'
      $ ./clusterrun.sh 'gcc /home/cluster/work/mysource.c'
      $ ./clusterrun.sh '/home/cluster/work/a.out'

      Anyway, that's all there is to it.
  • I am one, and I hate seeing that mistake over and over again. If you can, please correct that.
    Thank you.

  • lost in the noise (Score:3, Insightful)

    by g4dget ( 579145 ) on Saturday September 14, 2002 @05:58AM (#4256199)
    The *BSD kernels may be a little more reliable and simple, and the Linux kernel may support more drivers, but it seems to me the differences are pretty much lost in the noise.

    I think Jobs had the right idea when he picked Mach as the basis for NeXTStep: he wanted a kernel that looked like UNIX from the outside but that was much more componentized than the UNIX kernels of the time, or BSD/Linux today. I don't know whether Mach/Darwin is the best choice for that, but in general, I think it's where open source needs to go.

    After all, we don't recompile Bash or dynamically load libraries into Bash every time someone comes out with a new command line program. We shouldn't have to do that either for a new file system type, networking protocol, or driver. And expending much time on a BSD/Linux rivalry isn't going to address such issues.

    • After all, we don't recompile Bash or dynamically load libraries into Bash every time someone comes out with a new command line program.

      No, but you could, if you needed it to be a shell builtin for performance or other reasons.

      We shouldn't have to do that either for a new file system type, networking protocol, or driver.

      You still have to write and compile something - why not a kernel module?

      Kernel modules, in Linux and other Unix variants, has greatly decreased the need for a message-passing kernel architecture. You get the modularity without the performance hit or the design weirdness to work around the performance hit.

      Not that OS X is actually a microkernel OS! It's more like MkLinux or User-Mode Linux [slashdot.org], in that one kernel is running on top of another but basically only using the host kernel for access to the hardware.

      • Close but, no cigar.

        xnu (the Darwin kernel) has both the BSD and modified Mach 3.0 compiled into one file and running in the same memory space.

        xnu is a hybrid kernel that keeps some of the advantages of microkernels (easy porting, etc.) but, has some of the advantages of a monolithic kernel (speed, etc.)

        xnu itself is pretty fast but, OS X's display server etc. (high level stuff) aren't as much but, are getting there.

        • Re:lost in the noise (Score:3, Informative)

          by be-fan ( 61476 )
          Actually, Darwin is about half as fast as Linux on the same hardware for basic kernel operations (mmap, open, etc). And its subsystems (especially the VM) aren't anything to brag about in comparison to their counterparts in FreeBSD and NetBSD.

      • Re:lost in the noise (Score:3, Insightful)

        by g4dget ( 579145 )
        No, but you could, if you needed it to be a shell builtin for performance or other reasons.

        Indeed. When I do need the performance, it would be nice to be able to load modules dynamically. But for something like IPsec, PPP, UFS, ISO9660, CMOS, etc., I don't need the performance; maybe you do on your big server, but I don't, on my little laptop. As for "other reasons", there shouldn't be any reason other than performance to load something dynamically.

        You still have to write and compile something - why not a kernel module?

        Because, empirically, kernel modules seem to end up being very dependent on kernel versions; if they weren't, distributions like Debian wouldn't ship with different collections of most kernel modules for each kernel, they would ship with one kernel module per package for each function/driver, without much of a notion of a "kernel version".

        Another reason is that one bug in one kernel modules brings down the whole thing. That's unnecessary and makes driver development a huge pain.

        Not that OS X is actually a microkernel OS!

        I made no claims about what it is or even whether it is a good architecture. What I claimed was that Jobs correctly identified a problem and tried to address it as best as possible with the software available at the time.

        And I think he actually succeeded much more than Linux did in this particular regard: kernel extensions on OS X work much better than on Linux.

        (Jobs also correctly identified the problem with C/C++ GUI toolkits and his solution, Objective-C with DisplayPostscript, probably also was the best technical compromise at the time, but I think that choice hasn't turned out as well as his choice for kernel--OpenStep and Cocoa ended up with most of the same problems as other GUI toolkits.)

        • Because, empirically, kernel modules seem to end up being very dependent on kernel versions; if they weren't, distributions like Debian wouldn't ship with different collections of most kernel modules for each kernel, they would ship with one kernel module per package for each function/driver, without much of a notion of a "kernel version".
          >>>>>>
          That's more attributable to the fact that Linus doesn't want to freeze the driver API rather than any fault of the design. BeOS (and Windows!) both use dynamically loaded drivers into kernel space, and they work just fine (Windows' other design weirdness aside).

          Another reason is that one bug in one kernel modules brings down the whole thing. That's unnecessary and makes driver development a huge pain.
          >>>>>>>>
          Umm, the same thing happens with most OSs. If it works for a 64-proc Solaris box, it sure as hell is good enough for my laptop! Given that OS X runs everything in kernel space, it isn't immune to this either.
          • That's more attributable to the fact that Linus doesn't want to freeze the driver API rather than any fault of the design.

            If, after 10 years of hacking, it's not possible to provide a basic set of APIs for drivers, file systems, and other common kernel components, then the design is at fault. If not anything else, the Linux kernel could have two sets of APIs: stable and experimental. Other kernel architectures, involving message passing, RPC, or objects, also force people to think about this rather than keep changing things around haphazardly.

            Umm, the same thing happens with most OSs.

            I don't know what "most" means, but there are certainly many ways of avoiding that problem. For example, if you write the kernel in something other than assembly or C/C++, it gets much harder to crash the kernel accidentally. If you build a message passing kernel, you can transparently move drivers in and out of kernel address space, trading off performance and safety as needed. It's only monolithic kernels written in an unsafe language that are this sensitive.

            Don't get me wrong: Linux has been a reliable workhorse for many years, and the functionality in it is wonderful. But I think these issues are really becoming the biggest obstacle to its more widespread adoption and use on the desktop, and it's only going to get worse. If people don't seriously start thinking about addressing this now, some other kernel will take over in a few years, and that would mean more hassle for everybody. There are many ways of fixing it (see above), but first the patient has to admit that there is a problem, and I don't see that happening yet.

            • If, after 10 years of hacking, it's not possible to provide a basic set of APIs for drivers, file systems, and other common kernel components, then the design is at fault. If not anything else, the Linux kernel could have two sets of APIs: stable and experimental. Other kernel architectures, involving message passing, RPC, or objects, also force people to think about this rather than keep changing things around haphazardly.
              >>>>>>>>>>>>&g t;
              Before you go faulting the design of the kernel, I'd ask you, what do you know that everyone hacking on the kernel doesn't. Face it, hardware changes, the goals of the OS change. Even now, if the driver API were frozen, it might be (for example) unsuitable for the NUMA machines that Linux is trying to target. Keeping the driver API fluid allows developers to fix stuff as needed, instead of being a slave to backwards compatibility. One thing an open source kernel gains over a closed-source one is more freedom with interfaces. GCC can keep breaking binary compatibility (and hence keep improving the ABI) because people can just recompile their software. Closed source OSs can't do that, and there is no reason for Linux to try to emulate that undesireable behavior.
              Umm, the same thing happens with most OSs.

              I don't know what "most" means, but there are certainly many ways of avoiding that problem. For example, if you write the kernel in something other than assembly or C/C++,
              >>>>>>>>
              You've immediatly lost all credibility right there. In the real world, people don't use sissy languages like Scheme to do OS programming. Its ASM and C, live with it.

              it gets much harder to crash the kernel accidentally.
              >>>>
              And you lose all semblence of performance.

              If you build a message passing kernel, you can transparently move drivers in and out of kernel address space, trading off performance and safety as needed.
              >>>>>
              If you're drivers are bothering you that much, you've got a problem. I've used some pretty flaky drivers in the past (NVIDIA's early kernel drivers) and I have yet to crash the kernel due to a driver problem. This is a dead horse. People long ago figured out that existing architectures were just not designed for microkernel systems, and that the saftey of a message passing interface did not justify the overhead required to give drivers access to the hardware. Even OS-X realized this, and put the whole kernel back in kernel-space, and replaced messaging with procedure calls.

              It's only monolithic kernels written in an unsafe language that are this sensitive.
              >>>>>>>>>
              Which is basically all of them. And they are that way for a reason. Besides, the fact that you use the word monolithic identifies you as a throwback to the 1990's. There are no monolithic kernels anymore, they're all modular. They don't have the safety of microkernels, but have all the advantage of seperating out components, and that's always been the real win.

              Don't get me wrong: Linux has been a reliable workhorse for many years, and the functionality in it is wonderful. But I think these issues are really becoming the biggest obstacle to its more widespread adoption and use on the desktop, and it's only going to get worse.
              >>>>>>>>>
              People don't go, "I don't use Linux because its not a microkernel written in Scheme," people say "I don't use Linux because it doesn't have the software I need." I mean what problem exactly are you trying to solve? Instability? Come on, not even MS claims that Linux is unstable. How about ease of use? Nope. As long as you're using an easy distro like Redhat or Mandrake, driver updates are a simple urpmi kernel-2.4.XX away. These days, there is very little mainstream hardware not supported in the stock kernel. On my Inspiron 8200 laptop, for example, every single gadget I have, from my USB mouse to my Pocket PC to my QuickCam is supported in the stock kernel. There is simply no reason to install outside drivers. And because there is no reason to do that, it makes no sense to limit the kernel developers just so the 3 people that distribute seperate drivers can have a stable ABI.
              • Before you go faulting the design of the kernel, I'd ask you, what do you know that everyone hacking on the kernel doesn't. Face it, hardware changes, the goals of the OS change.

                Microsoft, Apple, Amiga, and BeOS manage to make it work. It's only Linux that, in practice, seems to require kernel recompilation for many installations and distributions.

                In the real world, people don't use sissy [...]

                Look, I'm speaking as a user. I don't care about your (mis-)conceptions about software engineering or systems programming, I'm not suggesting any specific solutions for Linux. I'm telling you: the Linux kernel is my biggest headache in maintaining Linux desktops and servers. All the other stuff is handled wonderfully by the standard packaging and configuration systems.

                On my Inspiron 8200 laptop, for example, every single gadget I have, [...]

                Yes, the rallying cry of a software developer who doesn't care about users: "I like the way it works". And that's fine. If the Linux kernel developers don't want to fix that, that's their choice, that's the way open source works. But if they want continue to see widespread usage by others, I predict they need to fix this, because a kernel without this deficiency (from the point of many users) will come along sooner or later.

                Example: IPsec. Not included in the standard kernel. In order to get it working, I'll have to patch, configure, and recompile kernels for half a dozen different machines. For handhelds running Linux, this will be even more of a chore.

                And because there is no reason to do that, it makes no sense to limit the kernel developers just so the 3 people that distribute seperate drivers can have a stable ABI.

                Yes, and that is one of the problems: rather than fixing the kernel, kernel developers just stick more and more drivers into the kernel source tree.

                People don't go, "I don't use Linux because its not a microkernel written in Scheme," people say "I don't use Linux because it doesn't have the software I need."

                I agree 100%. And the software they need that isn't working is the drivers and other kernel modules they need to get their hardware working and communicate with the rest of the world.

                • Example: IPsec. Not included in the standard kernel. In order to get it working, I'll have to patch, configure, and recompile kernels for half a dozen different machines. For handhelds running Linux, this will be even more of a chore.
                  >>>>>>
                  If you need IPsec, then you can certainly recompile your kernel. The thing is that external stuff like IPsec is entirely analagous to external stuff in Windows. For example, Windows prior to Win98 SE didn't come with any NAT capability. Installing an add-on like raspppoe took a good bit of work. IPsec isn't a part of the standard Linux installation. Thus, it is to be expected that installing it takes some extra work.

                  Yes, and that is one of the problems: rather than fixing the kernel, kernel developers just stick more and more drivers into the kernel source tree.
                  >>>>>>>>>>
                  There is no problem to fix. If the kernel developers wanted a standard ABI, they could have done it long ago. But they didn't for a reason. PC hardware changes too quickly for that to be feasible. Look at Windows and how long it takes them to support advances to PC hardware. Why? Because they have to be very careful that any changes they make don't break old binary drivers. Both Linux and Windows were designed at a time when drivers needed to know nothing about power management or ACPI or hotplugging. Now, drivers need to know these things. To support this, Windows has all sorts of strange interfaces (writing Windows drivers is a lot harder than writing UNIX drivers. I/O request packets and whatnot are a bitch). Linux has had to break interfaces, but the end result is much cleaner and more managable. As for adding more drivers, that's a good thing. The more drivers that are in the standard tree, the more support there is for hardware out of box.

                  I agree 100%. And the software they need that isn't working is the drivers and other kernel modules they need to get their hardware working and communicate with the rest of the world.
                  >>>>>>>>>>
                  Again, what hardware drivers are you talking about? If you're using a modern distribution, everything should be supported out of box. If it isn't, then consider it a piece of hardware that Linux doesn't support by default. Just as Windows doesn't support certain hardware out of box. Both take some work to get running.
                  • If you need IPsec, then you can certainly recompile your kernel.

                    So, you admit it, you just don't think it's a problem. Well, wake up and smell the coffee: for real-world installations, this is a problem. Both sys admins and users have better things to do than recompile kernels.

                    If you're using a modern distribution,

                    I'm using Debian and RedHat.

                    everything should be supported out of box.

                    Well, it isn't on the majority of machines that I have installed. It's things like ACPI, Mosix, audio cards, on-board networks, Bluetooth, FireWire, multimedia, USB devices, and file system types.

                    Just as Windows doesn't support certain hardware out of box. Both take some work to get running.

                    On Windows or MacOS, I can download a ready-made driver package and install it. On Linux, I should be able to do an "apt-get install bluetooth-drivers" or "apt-get install ipsec-kernel-module", and it should download a few hundred kilobytes at most, but no distribution has figured out how to make that work. And that's the problem.

  • The Secret to BSD Trolls (Score:3, Funny)

    by dirtyhippie ( 259852 ) on Saturday September 14, 2002 @06:04AM (#4256207) Homepage
    I just figured it out!

    The Secret to BSD Trolls! ...Is that they are actually written by BSD users themselves, in an effort to keep lamoid linux users from making statements on their mailing lists like:

    - FreeBSD is my favorite linux distro!

    - How do I copy stuff under BSD? I tried clicking
    all over the place, but I don't see a cursor or
    anything.

    - I know the install was completely self
    explanatory and all, but I really prefer
    Mandrake/Redhat's GUI installation. Can you
    give me pointers on porting it? Oh yeah, I want
    that little penguin, errr, i mean daemon screen
    on boot too. Who needs kernel messages?

    - When I try to build a port, and it says
    checksum mismatch, how do I override it?

    - OpenBSD is elite. No one can hack me! Oh yeah.
    I also forgot my root password, can someone
    help? My IP is x.x.x.x...

    - I just installed NetBSD on my { insert old or
    obscure hardware here }, but I can't play Doom
    under an i386 emulator running linux emulation
    of wine. Why?

    - How will running "rm -rf /*" fix my problem
    again?

    Keep up the good work, guys! :-) Hope I'm not giving away your secret!

    Peace,
    DH

    Yeehaw! Time to lose some karma!
  • My javastation's are once again obsolete... time to upgrade.

  • Learning about Unix. (Score:3, Informative)

    by saintlupus ( 227599 ) on Saturday September 14, 2002 @09:12AM (#4256587)
    I think that NetBSD is possibly the best system for a newbie who really _wants_ to learn Unix, if only because it's so bare-boned that you have to figure out the whole thing to get any work done.

    My first experience with it was on an old Quadra 700 Macintosh, which I installed NetBSD 1.4.something on to try and get used to using a command line. Outside of the sun boxen at the college I attended, I hadn't used a shell prompt before, but I wanted to figure out how to get things done before OS X came out.

    Well, NetBSD isn't what I'd call "user friendly," especially the installer for the Mac68k port. But I managed to figure it out, and by bothering the hell out of the local Linux and Solaris geeks, I managed to get everything up and running properly.

    By the time OS X came out, I wasn't prepared to give up the BSDs I've come to appreciate - so I've got a NetBSD box, one for OpenBSD, and one for FreeBSD on my network. They're all hand-configured to the purposes I need them for. And all that time meant that I have a much better grasp of how my systems fit together than any of the l33t haX0rs at work with their Mandrake installs and their deep fear of the command line.

    In short, if you want to learn a particular distros tools, install some flavor of Linux and use the administration stuff that comes with it. But if you want knowledge that bridges between Unix variants, give NetBSD a shot. You'll be pleasantly surprised.

    --saint
    • Indeed, NetBSD is quite bare-boned, at least that's what I've noticed from the few installs I've done. Everyone says how bare-bones OpenBSD is, but it's actually quite full-featured compared to the other BSDs and Linux distributions. With OpenBSD, you really have a full-featured general-purpose server right out of the box (just edit rc.conf to suit) whereas NetBSD does require more in-depth configuration. But it's a great learning experience, and once you're done you know exactly what's on the machine and what it's doing. By the way, I find NetBSD to be a screamingly fast OS. Even more so than FreeBSD. Given the similarity among the BSDs, it's surprising that performance differences are so noticeable.
  • As restrictions come in to play for new hardware, ( drm, etc ) NetBSD will slowly begin to play a very important role keeping old 'unencumbered' hardware alive. ( and freedom ).

    Is it just me, or does all the BSD news around here get more then its share of idiot trolls?

  • Sushi? (Score:1, Interesting)

    by Anonymous Coward
    Anyone got any thoughts or experiences on Sushi, the new menu-driven admin program in NetBSD 1.6? This is one of the more interesting user-visible developments -- FreeBSD has SysInstall, NetBSD now has Sushi and OpenBSD... well, that's up to Theo :)

    But seriously, this could be a great step-up for NetBSD's image and user-friendliness. Anyone tried it?

    (Stuck on 56k modem atm; will download later)

  • . . .you could toast the whole loaf at once.

    (Sorry 'bout that.)

  • Forget the ports, I like NetBSD because it is bare-bones. After trying NetBSD both FreeBSD and Debian seems bloated for me.
    I like the quality of code and documentation too. It is amazing for learning Unix.

    I don't like OpenBSD because of that stupid fish. Long live beastie! (-:

  • heh (Score:1)

    by khold ( 164649 )
    The first time I read through the article blurb, I read the following: NetBSD is widely known as the most popular operating system in the world

    That made me do a double take, or in this case, a double read.

  • NetBSD eggs, sausage, bacon, and ham. Delicious ham. Roll on, eggs! Roll on, sausage, roll on, ham!

Slashdot Top Deals

You do not have mail.

Close