Slashdot Mirror

← Back to Stories (view on slashdot.org)

New NetBSD/amd64 Snapshot

Posted by timothy on from the runs-everywhere dept.

fvdl writes "As the number of AMD64 users grows, new snapshots of NetBSD/amd64 will be made available on a regular basis, until the next NetBSD release (2.0) is out. NetBSD/amd64 is almost two years old by now, but did not have a formal release yet, since hardware was not publicly available at the time of the last major NetBSD release. The latest snapshot is available at ftp.netbsd.org. It is a fully-featured NetBSD port, made available in the form of a bootable ISO image."

25 comments

  1. Why? by Orthanc_duo · · Score: 1, Flamebait

    Why do they need a port for AMD.. AMD chips still run the x86 command set don't they??
    or has it just been optimised for AMD processors?

    1. Re:Why? by nitehorse · · Score: 5, Informative

      This is for the K8/Sledgehammer/Opteron architecture - NetBSD runs in full 64-bit mode on it.

    2. Re:Why? by zzyp · · Score: 1

      Why do they need a newer gcc to compile 64 bit code? The current ones dont do that now eh?
      I am waiting till next year to assemble myself a nice 2+ Ghz AMD64 machine.

    3. Re:Why? by hubertf · · Score: 4, Informative

      The amd64 platform is a true 64 bit platform (hence the name :). As such, it uses 64bit entities for longs and pointers internally, which is just not compatible with the legacy PC software.

      To still run legacy software, an emulation layer had to be added that maps all 32bit entities (longs, pointers, ...) that applications pass on system calls into their 64bit in-kernel equivalents, and back.

      That emulation layer was already necessary for the NetBSD/sparc64 port, to run NetBSD/sparc (and 32bit Solaris, etc.) binaries on 64bit platforms. It was not necessary for the NetBSD/alpha port, as there are no 32bit binaries, and it can operate in 64bit without taking care of backward compatibility.

      Would be interesting to hear how other operating systems deal with the situation btw - FreeBSD, Linux, Windows anyone?

      - Hubert

    4. Re:Why? by the-dude-man · · Score: 1

      Basically its so you can compile for the single set of 64 bit registers in the cpu

      Without it, There really isnt a whole lot of point in using an Athlon64 cpu.

      You may use AlthlonXP and get half the price and a bigger space heater if you use the 32Bit binarys

  2. Why not? by rumpledstiltskin · · Score: 2

    optimizing an operating system for a processor is probably a good thing. you can make apps go that much faster, and it would probably be more stable. the only downside is it may lead to a fragmentation of the operating system (countered by the upside of expanding the user base, though)

    1. Re:Why not? by compudroid · · Score: 5, Informative

      NetBSD prides themselves on their clean code working on over 50 archs i beleive. 30 something considered stable. Adding a port to a new arch hasnt fragmented NetBSD thusfar, I see no reason why this one would.

      --


      -CompuDroid
      http://www.zoo-crew.org
    2. Re:Why not? by evilcyber · · Score: 1

      Actually, the number is 40+.

      (As of this writing, there are 40 arches in the automated build loop, amd64 has not yet been added to the autobuild.)

  3. FreeBSD AMD64 support: by Anonymous Coward · · Score: 0
    The 5.2R todo list has this:

    "Productionable support for the AMD64 platform.

    Currently, AMD64 runs fully in 32-bit emulation mode, and boots to single-user in 64-bit mode. We expect full production support for the AMD64 architecture in 5.2-RELEASE."

    So it's sorta working and to be finished soon.

  4. Anatomy of a failure: What Killed FreeBSD by Anonymous Coward · · Score: 0
    The End of FreeBSD

    [ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

    When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

    Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

    FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

    It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

    So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

    Discussion

    I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

    From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

    There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

    Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

    Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

    Shouts

    To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

    To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It'