Slashdot Mirror

Give it up, no general purpose computer operating system that could even be considered close to mainstream uses a microkernel approach. It's a dead end but for very specific embedded applications.

I'm not sure what counts as "mainstream," i.e. whether it's about popularity or use cases, but NetBSD uses a novel "anykernel" design that kind of makes microkernel-vs-monolithic arguments obsolete.

*BSD uses Mozilla's root certificate bundle.

There are many other OS to use on ancient hardware. Some cited Slackware, there is also NetBSD.

I was curious since I'd never heard of this problem before (or even had a clue of what the problem was about). I was led to this blog post, which is quite interesting. The issue is having the same source tree always build an identical cdrom. On the surface it sounds simple, but a surprising amount of work was needed to make it happen, all detailed in the blog post. I can't help but admire the obsessive perfectionism that won't leave the problem alone until it is completely resolved.

NetBSD's pkgsrc collection has been designed to be portable. I believe it's already been ported to Slackware, and Solaris and other OSes.

The tools exist to just import it into this new Linux flavor.

Or if you're just trying to escape systemD madness, just use NetBSD. Or one of the other freenix choices that already has a package system built for it.

Of course, if you want it to be really secure you write protect the system partition after you install it. (This generally means, in Linux, that you need to create a bunch of hard links from your system partition to another partition that you allow writes to, so that, e.g., the /tmp directory can be written to. I'm not sure anymore what the BSD equivalent to that is.

It's called different mount points. And on Linux, I doubt the super user cannot just remount the partition read-write again (don't know about OpenBSD, but NetBSD prevents this with the securelevel concept)

Hard links won't help you in any way.

Er, last I checked, some guy, with a .nl e-mail address, AFAIK not related to the NetBSD project, had filed a bug about removing the Hitler quotes.

One committer fixed the bug by removing the quotes.

They were reinstated five hours later because the discussion on the mailing lists was still ongoing.

No other related commits have happened in the five days since.

How do you make out of that that they are "mentally weak"?

Er, last I checked, some guy, with a .nl e-mail address, AFAIK not related to the NetBSD project, had filed a bug about removing the Hitler quotes.

One committer fixed the bug by removing the quotes.

They were reinstated five hours later because the discussion on the mailing lists was still ongoing.

No other related commits have happened in the five days since.

How do you make out of that that they are "mentally weak"?

NetBSD/xen is a port of NetBSD to the Xen virtual machine monitor.

NetBSD/xen has been around since 2004.

> We tried AmigaUX in 1994 in CompSci. Didn't work all that well.

Do you mean Amix? That's not Linux!

Now NetBSD I'm tempted to get an Amiga just to try...

Have you looked at NetBSD's rc.d init system?

Maybe that could be adapted to Linux.

BSD based Unix systems have this for along time.
Both in the base system, and for 3rd party software.

Base system example:
http://cvsweb.netbsd.org/bsdwe...

Then again, there's not much need for "autoconf"-like system environment detection there. The actual build system is also in a lot of Makefile snippets in the share/mk directory:
http://cvsweb.netbsd.org/bsdwe...

For 3rd party software that's build from a make-based system, see http://www.pkgsrc.org/

BSD based Unix systems have this for along time.
Both in the base system, and for 3rd party software.

Base system example:
http://cvsweb.netbsd.org/bsdwe...

Then again, there's not much need for "autoconf"-like system environment detection there. The actual build system is also in a lot of Makefile snippets in the share/mk directory:
http://cvsweb.netbsd.org/bsdwe...

For 3rd party software that's build from a make-based system, see http://www.pkgsrc.org/

This renders your joke irrelevant, but NetBSD can run some Linux binaries.

Read about it here: https://wiki.netbsd.org/guide/linux/

The NetBSD port for i386, amd64, mac68k, macppc, and many others can execute a great number of native Linux programs, using the Linux emulation layer. Generally, when you think about emulation you imagine something slow and inefficient because, often, emulations must reproduce hardware instructions and even architectures (usually from old machines) in software. In the case of the Linux emulation, this is radically different: it is only a thin software layer, mostly for system calls which are already very similar between the two systems. The application code itself is processed at the full speed of your CPU, so you don't get a degraded performance with the Linux emulation and the feeling is exactly the same as for native NetBSD applications.

FreeBSD has similar functionality.

This is one of the reasons why so many former Linux users have moved to FreeBSD or NetBSD after being driven away from Linux by systemd, PulseAudio, GNOME 3, and other problematic software like that. Most Linux programs worth using compile just fine on the *BSDs, but if there are legacy, closed-source Linux applications that must be used there is at least some chance that they may work on FreeBSD or NetBSD. This makes for a very easy transition path away from Linux, or more correctly, away from systemd (it isn't the Linux kernel itself that most people have problems with, of course).

> Fossil was meant to be a 'lite' DVCS

Fossil was meant to support the needs of SQLite, one of the most popular and actively-developed code bases in the world. If Fossil can meet its needs, chances are good that it can meet your project's needs, too. There are very few NetBSD-scale projects out there, compared to the number that are plenty fast under Fossil.

And yes, I'm aware that you could list hundreds of projects at that scale, but I believe I could find millions software projects smaller than that. If you try to argue against this point, you'd be arguing a 0.01% type of position. I'm happy with Fossil going after the other 99.99%.

> Hell, it uses SQLite as its storage backend.

This is a problem how?

The biggest single problem with SQLite from a performance standpoint is that it doesn't have row-level locking, limiting its use in concurrent systems. SQLite has multiple-reader, single-writer concurrency, but multiple writers to a single DB file serialize their writes to a single table. SQLite will let multiple writers can modify separate tables at the same time, but I'm going to assume Fossil has some usage pattern that requires that all commits to hit at least one common table.

According to NetBSD's source-changes mailing list there are only about forty commits per day, so even at that scale, concurrency is simply not an issue.

Projects like NetBSD don't get to be behemoths over night. It takes 40 commits per day for 25 years to make that happen.

SQLite's other big limitation is that it isn't a client-server DBMS, so when you need multiple clients over the network to access the DB, you need some intermediary to provide that access. The naive approach is to use a networked file system, but this is likely to cause problems. But we don't have that problem with Fossil: we have fossil server, which exposes the DB over HTTP. Since a single process is manipulating the central DB, which is a local file to it, there can be no locking problem. If by some small chance two users need to commit at the same time, fossil server will serialize the commits.

> It's a lovely DVCS otherwise.

I agree. The vast majority of the users of Git today could run just as well on Fossil.

I'll just leave this here.

For various legal reasons FreeBSD pretended it was based on 4.4BSD-Lite for a long time. The NetBSD guys went as far as settling out of court and deleting 386BSD stuff from their cvs history. See eg. http://cvsweb.netbsd.org/bsdwe...

He's... not even wrong. It's rather impressive, the number of misconceptions and sheer volume of ignorance he manages to cram into just six short paragraphs.

It was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout.

Except that it wasn't by default. You logout, your shell gets the HUP signal. That signal gets propagated down to all of the shell's children, and all of their children, and their children - all the way down to the end of the chain. By default, HUP terminates a given process. If it doesn't terminate a process as described, it's because one of three things has happened. First possibility: the process has deliberately severed its child-parent relationship with the shell, as any program designed to run as a daemon will do. Second possibility: the process has explicitly set a signal handler to trap (or ignore) the HUP signal. Third possibility: the process has been launched with the nohup command (which effectively is the same as the second possibility).

If a program hangs around after logout that isn't supposed to, that's a bug in the program, not in the operating system. The defaults are all set up properly; if a program deliberately sets out to ignore them, presumably that's for a good reason.

It has never been the default that a program will just hang around forever for no good reason.

we should consider it our duty as Fedora developers to improve the Linux platform

Right. That's it. I'm done. I'm out. I've been involved with Linux in some form or another since the days of the a.out to ELF transition - over ten years. I've been grumbling about systemd breaking a whole bunch of conventions for no good reason since I first laid eyes on it. This? This is the straw that broke the camel's back. Any operating system that quietly introduces a breaking change like this - something that is a fundamental part of the design of the Unix operating system, that is a basic assumption that every long-term Unix user is aware of - is not an operating system I want to have to deal with. Sure, it's easy to change the configuration setting for this thing. What about the next change that breaks something fundamental? Or the one after that? Or the one after that?

This isn't good enough. Sure, sometimes change is necessary - the a.out to ELF transition was done for good reasons; swapping out telnet to ssh was done for good reasons - but this kind of subtle breakage is a huge time sink to any halfway serious systems administrator.

Well, at least there are alternatives out there.

IIRC the kernel dropped boot floppies around version 2.6

Last time I installed OpenBSD and NetBSD they installed from one and two floppies each if I remember correctly.

Back before then I think Debian maybe had like five or something..

See, this is how it's done:
http://ftp.eu.openbsd.org/pub/... - The _ONE_ floppy required to net-install OpenBSD 5.9 i386.
http://ftp.eu.openbsd.org/pub/... The _ONE_ floppy required to net-install OpenBSD 5.9 AMD64.

Wow, NetBSD uses _FIVE_ floppies now?!
http://ftp.fi.netbsd.org/pub/N...

FreeBSD doesn't even offer floppy-installation any more?
ftp://ftp.se.freebsd.org/pub/F...

NetBSD just added Raspberry Pi 2 support
https://wiki.netbsd.org/ports/...
https://wiki.netbsd.org/ports/...

Why do you want OpenBSD? Their video support is crap. If you want a router, there are better devices which do run OpenBSD.

NetBSD just added Raspberry Pi 2 support
https://wiki.netbsd.org/ports/...
https://wiki.netbsd.org/ports/...

Why do you want OpenBSD? Their video support is crap. If you want a router, there are better devices which do run OpenBSD.

Microkernels are very complex by comparison, and it's turning out to not be a practical idea. If you want to try one out, go download GNU Hurd, it's a microkernel.

Why would you mess around with HURD when you can play with L4 or Minix 3 ?

You could also try NetBSD which is based on an "anykernel," using "rump kernels" to allow drivers to run in either kernel space OR user space.

All of these are more mature and stable than HURD.

Ubiqiti EdgeRouter is exactly this: dual core MIPS64 @ 1Ghz, 512Mb memory and a removable USB flash stick for storage.
https://www.ubnt.com/edgemax/e...
This is ample for my needs. I bought the 3 port version about a year ago for £80.

https://blog.netbsd.org/tnf/en...

As of today, NetBSD-current has an uptime of about 6 months - which is when I made the last kernel modifications to support the NPF firewall.
This is more uptime than any other SOHO gear I have and the performance of the unit is exceptional.

I wouldn't call NetBSD the least stable. Porting an OS to many different architectures shakes out a lot of bugs that you don't see with an architecture that plods along running on only one or a few platforms.

The BSDs, particularly NetBSD and FreeBSD, are very compact, and there's only one 'distribution' of them. When a tag is laid down for a new version, it's not just a kernel, it's an entire core userland that can be checked out, updated, and built consistently. BSD isn't a 'distro' because it's not composed of whatever dogs breakfast of utilities and toolchains one particular person or group kludged all together to call a 'distribution.' And the core installer for a BSD is compact and quick to install. The NetBSD 7.0 i386 installer iso is only 414,408 KB.

Not this bullshit again, technically NetBSD achieved this way before https://www.netbsd.org/ports/.

Take a look at NetBSD's rump kernel/anykernel design. It's really interesting!

While what you say was roughly true (though MS themselves used it internally to do things like host Hotmail for years) for the early versions, Interix (the name of the runtime environment - or pseudo-OS - that ran in the POSIX subsystem) versions 3.5 (XP) through 6.1 (Win7) were all quite usable. They added features that made it a lot more capable than most people seem to realize. I'm not claiming it didn't still have limitations (mostly in the forms of APIs that are common on modern *nix-like systems being missing) or bugs (though the 6.1 release quashed most of the worst of those), but it was quite usable and in many ways (speed, user account management, file system conventions, etc.) better than Cygwin.

The most obviously missing thing, in terms of day-to-day usability, was software package support; you could build your own (after getting and building all the dependencies) but it wasn't usually very pretty. There were a number of attempts to solve this, of which the two most notable were InteropSystems/SUACommunity (a now basically defunct site; Microsoft was funding it and stopped when Win8 deprecated the Unix subsystem) and NetBSD pkgsrc. SUACommunity offered a fairly-usable collection of pre-built binaries (including useful things like newer compilers than MS provided and compatibility shims to implement functions missing from the official Interix SDK), while pkgsrc offered a *huge* collection of software (comparable to a typical Linux distro) in source form, with scripts to build and install it in Interix.

I used Interix, with great success, for years. I used it on school projects (faster and needing less HD footprint than dual-booting or virtualizing Linux on Windows), I used it (bash, from SUACommunity) as my everyday shell, I used its tools (everything from sed to git) for everyday operations (even piping output between Win32 and POSIX programs) both at home and at work, I used its openssh server to remotely access my Windows box (and of course used its client too, including for X forwarding, though I had to use the Win32 "Xming" server), and I used it to compile programs that would only build on *nix but that I wanted to run on Windows. It was one of the first things I installed on any new Windows machine (helped that I had MSDN access so I could get the supported Windows versions).

I was really pissed when Microsoft deprecated that subsystem. It was still usable for a while, of course, but with the SUACommunity site losing funding, its repo became dangerously outdated and then went offline entirely. I wasn't willing to run code (especially stuff like git and ssh/sshd) with known vulnerabilities, wasn't interested in maintaining the packages from source, and knew I'd eventually want to move to Windows versions that didn't support Interix at all.

MSYS helps provide the stuff I need, like git. Cygwin has gotten better than it used to be, though (last I checked) it still fails on some things that Interix could handle (like case-insensitive file system behavior and sudo). PowerShell is, once you learn it, actually preferable to a Unix shell for most purposes. Hardware is now cheap/powerful enough that virtualizing is no longer a significant burden on most machines. In the end, though, I still find myself really missing the easy power and interoperability of Interix.

Does BSD have Dtrace?

Yes why?

Yep, and it works well.

BTW, Jun has updated the image now that 7.0 is de-facto released (announcement still missing)

You can run NetBSD on the Raspberry Pi, you know. There's no reason to screw around.

Well, I suppose it can finally no longer be said that the Sparcstation 10 I keep here just for old times' sake can still run "current Linux distributions."

NetBSD and OpenBSD both run on the SparcStation 10 and they're actual UNIX operating system. http://wiki.netbsd.org/ports/s... http://www.openbsd.org/sparc.h...

This is a job fo IPsec tunnels. OpenVPN could also do the job. Linux, FreeBSD and OpenBSD has been cited. NetBSD can do it too. IMO NetBSD may have the path of least resistance but that is personal opinion.

Here is an entry from the NetBSD official blog on their progress for Creator Ci20 (the same board used for the Fedora port). It looks like there has been some good progress made already.

I think the BSDs are much more worthwhile than Debian: they produce code; Debian mostly just packages others' code.

NetBSD, DragonflyBSD, OpenBSD, FreeBSD. Pick one.

OpenBSD seems perpetually short on cash, yet they spend their time on very important projects (OpenSSH, LibreSSL, OpenNTPD) which are worth supporting even if you don't personally use them.

NetBSD and FreeBSD are tax-deductible in the US.

The fact that a sysadmin use[s] a shell command interpreter d[oes] not imply that the command[s] he call[s] are shell script[s].

So your idea of a sysadmin is someone who keeps typing the same commands over and over again, every day or week, rather than automating them in a script? Good grief.

I think that I have show[n] enough pro[of] that shell scripts are not as essential outside of system V init as you [] claim.

So you don't understand what a proof is, besides not having a faint clue of real-world systems administration. Duly noted.

Now, this do[es]n't prevent anyone [fr]o[m] us[ing] a shell to get a CLI [lol what] and to write some scripts if [they] like to do so. You seem to forget that the maintainers['] decision to switch to systemd is not to remove power [fr]o[m] the users, but to make the maintainers['] work [] eas[ier]

Ah, okay, maybe that's the issue then. Because so far i had assumed systemd would provide immediate benefits to the users, because that's kind of what a million pimply-faced systemd fanboys claim.

s[o] I don't understand how stressed you are about the systemd architecture.

I thought i had made that clear. Anyway, the recent 3-4 comments were more about shell scripting in general than about systemd in particular.

About the comparison between Linux and BSD kernel, you still fail[] to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes.

You clearly are a complete idiot and not paying attention, if you would actually follow this moronic discussion you'd have ran across:

I'd love to have them run *BSDs, but since they're even less meant for the 'GUI-only desktop' use case, the amount of work required to support that would require more than four admins (good ones of which are hard enough to find for linux already).

A reboot for a upgrade will not affect [???] the availability because it only affect[s] the users for a minute or so

Thanks for another demonstration of how all your sysadmin "knowledge" is purely theoretical and pulled out of your ass. Read this.

So I think we can at least agree that the upgrade on Linux is no[t] affecting your operation more that your BSD boxes.

That's only because the Linux server sits around idle unless it's 4am or an office machine is reinstalling.

And if you can really crash a[n] up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause[s] the crash.

I have already realized you're not paying attention, or mentally incapable of doing so, that was in a timespan of at least 5 years. And when talking about "Linux machines i've seen crashing", I'm not specifically referring to that one particular single FAI server. That's not to say that it hadn't had its share of problems, but the bulkload of Linux machines i've seen panicing happened in private contexts. I'm still not sure if you're seriously trying to say that Linux would be free of problems. But you're a troll or a raging zealot, so whatever.

I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...

I (obviously) know that p age, and had you cared to actually take a look at it, most of those SAs are userspace related, and we have evaluated every kernel-related one for whether it affects us or not. The user-accessible ssh login gateway was affected to some, and subsequently got rebooted.
Why am i explaining this to an armchair sysadmin?

Restarting services take[s] less time than rebooting (especially with systemd), this is less risky on a remote machine, and

The fact that a sysadmin use a shell command interpreter did not imply that the command he call are shell script. I think that I have show enough prove that shell scripts are not as essential outside of system V init as you used to claim. Now, this don't prevent anyone to use a shell to get a CLI and to write some scripts if he like to do so. You seem to forget that the maintainers decision to switch to systemd is not to remove power to the users, but to make the maintainers work more easy and reliable across multiples systems. I never stated that sysadmin should be forced to use GUI, and projects like systemd or NetworkManaged take care to provides very good CLI, so I don't understand how stressed you are about the systemd architecture.

About the comparison between Linux and BSD kernel, you still failed to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes. At some point you have to admit that the Linux box do something that your BSD boxes can't do. You never explain the part of the Linux kernel that cause the supposed crash, and I am very curious about this because triggering a kernel crash is usually not so easy.

A reboot for a upgrade will not affect to much the availability because it only affect the users for a minute or so, contrary to a stability problem like crash that could affect the users as long as someone take to reset the machine. So I think we can at least agree that the upgrade on Linux is no affecting your operation more that your BSD boxes. It you really have a particular problem with your Linux boxes, than must be something as severe as a kernel crash, not because of upgrade. And if you can really crash a up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause the crash.

I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...

Restarting services take less time than rebooting (especially with systemd), this is less risky on a remote machine, and this affect the availability far less than a reboot because many services are capable to handle restart very fast, and others services are unaffected. In industrial systems there are situation where we just want to upgrade some part of the system while still let running others realtime parts unaffected. You might be in a context where you can just reboot, but there exists others contexts with more constrains than in your environment. You can ignore this fact, as you can continue to insult me, this will simply change nothing to the reality of the facts. And no, our company don't charge per hour.

I would be more than happy to design any futures systems with systemd into it. I delivered my first design with systemd last week and given the success I see no reason to go backward. A mission/life critical aerospace system with not use a Linux kernel anyway. But for less critical functions, even in aerospace, this could done. In fact there is already exists systems running Linux in aerospace environment, it's not hard to find on the internet.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications

Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.

and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.

How aren't they related to systemd? I'm not following, I think.

The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

So you see how pointless it is?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.

Why do you put whitespace in front of question marks?

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Well, there is probably a lot of even more complicated methods.

I'm sorry to hear it.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I hope this one is simple enough for your use case.

No, it's not; and more to the point, I don't have a real "use case". As said:

The other day I had a spare machine sitting around [.........] [and then] I nuked [it]

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

All BSD can do it. My favorite is NetBSD, and here is some documentation: on setting up IP filtering

NetBSD runs fine on that stat stuff. Look for NetBSD on Jornada 720 in this page, running Doom as a demo

Which is what is currently happening to Linux, too. Escape Now ...bitches!

FreeBSD was there first.

While we are arguing about who was first,NetBSD 1.0 was released on 26th October 1994, although their formal release history goes back to 0.8 on April 20, 1993.

Don't forget though, that these BSD releases comprised the entire OS, though it was not written from scratch (heavily based on 4.4BSD), as the Linux kernel was (release 0.01 in 1991, according to wikipedia). The first BSD releases were back in the 1970s!

FreeBSD was there first.

While we are arguing about who was first,NetBSD 1.0 was released on 26th October 1994, although their formal release history goes back to 0.8 on April 20, 1993.

Don't forget though, that these BSD releases comprised the entire OS, though it was not written from scratch (heavily based on 4.4BSD), as the Linux kernel was (release 0.01 in 1991, according to wikipedia). The first BSD releases were back in the 1970s!

So is ESR trying to convert the NetBSD CVS repo in some weird and special way or something, and that's why it failed? Because it has already been converted and is on Github; if he needs info on how it was done, there's probably someone on the tech-repository mailing list that can help. It's been converted to Fossil too.

until the Systemd fiasco blows over.

Not going to happen.

If only there were sane and well-designed OS the developers of which actually think about the consequences of what they're doing.
Oh, wait. there are.

systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

Indeed. It shook me so hard, I fell off the Linux world.
Not looking back

...at all.

It is a "Tier 2" — so there are no official builds for it, for example.

It is a "Tier 1" for NetBSD, so you may have better luck there. They even distinguish between "ARM evaluation boards" (evbarm) and "StrongARM based Windows CE PDA machines" (hpcarm). I'm sure, OpenBSD is similar in this regard, but I'm tired of copy-pasting links...

It is a "Tier 2" — so there are no official builds for it, for example.

It is a "Tier 1" for NetBSD, so you may have better luck there. They even distinguish between "ARM evaluation boards" (evbarm) and "StrongARM based Windows CE PDA machines" (hpcarm). I'm sure, OpenBSD is similar in this regard, but I'm tired of copy-pasting links...

It is a "Tier 2" — so there are no official builds for it, for example.

It is a "Tier 1" for NetBSD, so you may have better luck there. They even distinguish between "ARM evaluation boards" (evbarm) and "StrongARM based Windows CE PDA machines" (hpcarm). I'm sure, OpenBSD is similar in this regard, but I'm tired of copy-pasting links...