Filesystem Hierarchy Standard (FHS) and OpenBSD

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Filesystem Hierarchy Standard (FHS) and OpenBSD

Jeff Licquia
(Sorry if this isn't the proper list for this discussion.  If not,
please point me in the right direction.)

The Linux Foundation's LSB workgroup has taken over maintenance of the
Filesystem Hierarchy Standard, and is working on a number of updates
needed since its last release in 2004.

Despite all the "Linux" in the names above, we're wanting to make sure
that the FHS remains independent of any particular UNIX implementation,
and continues to be useful to non-Linux UNIXes.

My question to you is: do you consider the FHS to be relevant to current
and future development of OpenBSD?  If not, is this simply due to lack
of maintenance; would your interest in the FHS be greater with more
consistent updates?

If you are interested, consider this an invitation to participate. We've
set up a mailing list, Web site, etc., and are reviving the old bug
tracker.  More details can be found here:

http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Damien Miller
On Mon, 9 May 2011, Jeff Licquia wrote:

> (Sorry if this isn't the proper list for this discussion.  If not, please
> point me in the right direction.)
>
> The Linux Foundation's LSB workgroup has taken over maintenance of the
> Filesystem Hierarchy Standard, and is working on a number of updates needed
> since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make sure that
> the FHS remains independent of any particular UNIX implementation, and
> continues to be useful to non-Linux UNIXes.
>
> My question to you is: do you consider the FHS to be relevant to current and
> future development of OpenBSD?

No, OpenBSD follows BSD traditions.

> If not, is this simply due to lack of
> maintenance; would your interest in the FHS be greater with more consistent
> updates?

No, it isn't a matter of update frequency. Viva la difference!

-d

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Marco Peereboom
In reply to this post by Jeff Licquia
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote:

> (Sorry if this isn't the proper list for this discussion.  If not,
> please point me in the right direction.)
>
> The Linux Foundation's LSB workgroup has taken over maintenance of
> the Filesystem Hierarchy Standard, and is working on a number of
> updates needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make
> sure that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.

Linux is very compatible with Linux and nothing else.  Give it up, call
it a day.  It doesn't even remotely resemble UNIX.

>
> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?  If not, is this simply
> due to lack of maintenance; would your interest in the FHS be
> greater with more consistent updates?
>
> If you are interested, consider this an invitation to participate.
> We've set up a mailing list, Web site, etc., and are reviving the
> old bug tracker.  More details can be found here:
>
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Kamo Hiroyasu
In reply to this post by Jeff Licquia
I do not understand the benefits of FHS for Unixen other than Linux.
Most Unixen, including OpenBSD, are older than FHS and have their own
historical constraints.  What do we obtain except for switching costs
if we accept FHS?

It is not we but FHS people that should explain the benefits.  If the
explanation is available and acceptable, we can accept FHS.
Otherwise, we neet not consider FHS.

Kamo Hiroyasu
[Kamo is the family name and Hiroyasu the given name.]

From: Jeff Licquia <[hidden email]>
Subject: Filesystem Hierarchy Standard (FHS) and OpenBSD
Date: Mon, 09 May 2011 23:33:27 -0400

> (Sorry if this isn't the proper list for this discussion.  If not,
> please point me in the right direction.)
>
> The Linux Foundation's LSB workgroup has taken over maintenance of the
> Filesystem Hierarchy Standard, and is working on a number of updates
> needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make sure
> that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.
>
> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?  If not, is this simply due
> to lack of maintenance; would your interest in the FHS be greater with
> more consistent updates?
>
> If you are interested, consider this an invitation to
> participate. We've set up a mailing list, Web site, etc., and are
> reviving the old bug tracker.  More details can be found here:
>
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Jeff Licquia
On 05/10/2011 12:28 AM, Kamo Hiroyasu wrote:
> I do not understand the benefits of FHS for Unixen other than Linux.
> Most Unixen, including OpenBSD, are older than FHS and have their own
> historical constraints.  What do we obtain except for switching costs
> if we accept FHS?
>
> It is not we but FHS people that should explain the benefits.  If the
> explanation is available and acceptable, we can accept FHS.
> Otherwise, we neet not consider FHS.

I would see standardization as its own benefit; app developers like
having a set of conventions they can rely on.

Perhaps, though, I'm not being as clear as I could be.  I'm not
necessarily advocating that OpenBSD adopt FHS; my goal is that, since we
are changing FHS, we not exclude anyone who wants to use it.  The
standard itself claims to apply to any UNIX-like system, and to not be
Linux-specific; I'm wanting to find out if that's true.

If it's not, all well and good; we proceed on our separate ways.  But I
don't want to assume that without asking.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Andrew Hewus Fresh
On Tue, May 10, 2011 at 01:21:15AM -0400, Jeff Licquia wrote:
> The standard itself claims to apply to any UNIX-like system, and to
> not be Linux-specific; I'm wanting to find out if that's true.

Perhaps then you would be interested in item 14 of the OpenBSD porting
checklist:

http://www.openbsd.org/porting/checklist.html

l8rZ,
--
andrew - http://afresh1.com

I wish life had an UNDO function.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Bryan Steele-2
Many UNIX systems include a hier(7) man page, OpenBSD is no exception.

http://www.openbsd.org/cgi-bin/man.cgi?query=hier&manpath=OpenBSD+Current&format=html

-Bryan.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Rod Whitworth-3
In reply to this post by Jeff Licquia
On Tue, 10 May 2011 01:21:
wrote:

>On 05/10/2011 12:28 AM, Kamo Hiroyasu wrote:
>> I do not understand the benefits of FHS for Unixen other than Linux.
>> Most Unixen, including OpenBSD, are older than FHS and have their own
>> historical constraints.  What do we obtain except for switching costs
>> if we accept FHS?
>>
>> It is not we but FHS people that should explain the benefits.  If the
>> explanation is available and acceptable, we can accept FHS.
>> Otherwise, we neet not consider FHS.
>
>I would see standardization as its own benefit; app developers like
>having a set of conventions they can rely on.
>
>Perhaps, though, I'm not being as clear as I could be.  I'm not
>necessarily advocating that OpenBSD adopt FHS; my goal is that, since we
>are changing FHS, we not exclude anyone who wants to use it.  The
>standard itself claims to apply to any UNIX-like system, and to not be
>Linux-specific; I'm wanting to find out if that's true.

See:
http://www.openbsd.org/cgi-bin/man.cgi?query=hier&apropos=0&sektion=0&ma
npath=OpenBSD+Current&arch=i386&format=html

I think the "claim" should never have been made. A blatant error like
that will hardly enhance the reputation of the "standard". The
"standard" only applies to those who choose to use it.

I've worked with many Unix/Unix-like OSes and the variations are
obviously so many and so different that anyone other than a
wet-behind-the-ears noobie or someone stuck with one OS for life would
know it.


>
>If it's not, all well and good; we proceed on our separate ways.  But I
>don't want to assume that without asking.
>

Lots of luck. The draft LHS was released (IIRC) in 1993 when I was an
IBM instructor. It never cut any ice really during my time there which
ended in 2005.

Six years later and still trying? Give 'em a tick for persistence.


*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Mark Kettenis
In reply to this post by Marco Peereboom
> Date: Mon, 9 May 2011 23:21:23 -0500
> From: Marco Peereboom <[hidden email]>
>
> On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote:
> > (Sorry if this isn't the proper list for this discussion.  If not,
> > please point me in the right direction.)
> >
> > The Linux Foundation's LSB workgroup has taken over maintenance of
> > the Filesystem Hierarchy Standard, and is working on a number of
> > updates needed since its last release in 2004.
> >
> > Despite all the "Linux" in the names above, we're wanting to make
> > sure that the FHS remains independent of any particular UNIX
> > implementation, and continues to be useful to non-Linux UNIXes.
>
> Linux is very compatible with Linux and nothing else.  Give it up, call
> it a day.  It doesn't even remotely resemble UNIX.

You got that wrong Marco.  Linux isn't even compatible with Linux
these days ;).

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Landry Breuil-6
In reply to this post by Jeff Licquia
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote:

> (Sorry if this isn't the proper list for this discussion.  If not,
> please point me in the right direction.)
>
> The Linux Foundation's LSB workgroup has taken over maintenance of
> the Filesystem Hierarchy Standard, and is working on a number of
> updates needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make
> sure that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.
>
> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?  If not, is this simply
> due to lack of maintenance; would your interest in the FHS be
> greater with more consistent updates?

Some parts of FHS won't apply on OpenBSD, like /srv, /opt, /libXX and /media.
I'm not even speaking of the /run promoted by systemd/fedora.
/boot is a file on OpenBSD, not a dir. And as pointed out, OpenBSD
makes a clear distinction between /usr (the basesystem) and /usr/local
(the apps installed by the package tools). Other than that, it looks
similar to our own FHS/mtree.

If FHS spec is changed to move those entries to the linux-specific Operating
System Specific Annex section, then it might make sense. Other than that,
i don't see much point. OpenBSD won't change its FHS for the pleasure of
LSB...

Landry

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Artur Grabowski
In reply to this post by Jeff Licquia
On Tue, May 10, 2011 at 5:33 AM, Jeff Licquia <[hidden email]> wrote:

> My question to you is: do you consider the FHS to be relevant to current
and
> future development of OpenBSD?  If not, is this simply due to lack of
> maintenance; would your interest in the FHS be greater with more consistent
> updates?

More updates will not atone for "/lib64".

//art

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Henning Brauer-5
In reply to this post by Jeff Licquia
* Jeff Licquia <[hidden email]> [2011-05-10 05:36]:
> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?  If not, is this simply
> due to lack of maintenance; would your interest in the FHS be
> greater with more consistent updates?

we'll happilly adopt FHS if you guys make it match hier(7).

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Ian McWilliam-2
In reply to this post by Artur Grabowski
On 10/05/2011 5:34 PM, Artur Grabowski wrote:

> On Tue, May 10, 2011 at 5:33 AM, Jeff Licquia<[hidden email]>  wrote:
>
>> My question to you is: do you consider the FHS to be relevant to current
> and
>> future development of OpenBSD?  If not, is this simply due to lack of
>> maintenance; would your interest in the FHS be greater with more consistent
>> updates?
> More updates will not atone for "/lib64".
>
> //art

At least /lib64  is better than winblows 64 bit systems

system32 <- 64 bit dll + apps
sysWOW <- 32 bit dll + apps

How's that for backwards compatibility.

Ian McWilliam

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Kevin Chadwick-2
In reply to this post by Landry Breuil-6
On Tue, 10 May 2011 09:05:13 +0200
Landry Breuil wrote:

> Some parts of FHS won't apply on OpenBSD, like /srv, /opt,

Linux ignores security mechanisms like noexec on /tmp, /home and then
pointlessly adds /opt seemingly just to annoy people who care about
partitioning!!

And DON'T try spinning me the line that noexec is pointless on /tmp.

I'm glad of your Open thought process though. :-)

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Thordur Bjornsson-2
In reply to this post by Jeff Licquia
On Mon, May 09, 2011 at 11:33:27PM -0400, Jeff Licquia wrote:
> (Sorry if this isn't the proper list for this discussion.  If not,
> please point me in the right direction.)
This is the proper list.
 
> Despite all the "Linux" in the names above, we're wanting to make
> sure that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.
Good, at least the Linux kids haven't totally forgotten the other
grumpies out there :)

> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?  If not, is this simply
> due to lack of maintenance; would your interest in the FHS be
> greater with more consistent updates?
> If you are interested, consider this an invitation to participate.
> We've set up a mailing list, Web site, etc., and are reviving the
> old bug tracker.  More details can be found here:
>
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

There are numerous show stoppers, IMO.

First off, the document is very Linux specific. Although I can't
back up the claim, I'm pretty sure that other OSes wheren't given
much thought in the early days of this document.

Here are what I would call, "show stoppers". And this applies to
OpenBSD, as I view it.

- OpenBSD has gone to great lengths to centralize all it's configuration
  into one place: /etc
  so anything contrarty to that, is a simple no go.

- A number of the directories do not make sense on OpenBSD:

  /lib
  For what libraries ? /bin and /sbin contains binaries that
  are statically linked (for a very good reason) so this is
  pointless.

  /opt
  Add-on application packages go into /usr/local/ on OpenBSD
  and the rest of the *BSDs
  Here there is one difference between Open and Free that I've
  come to dislike, FreeBSD stuffs configuration files into /usr/local/etc

  /media
  Mount point for removable media, okey; I thought that was
  what /mnt was for, and /mnt is still in the HFS ?
  (OK, I can see the point, just to help Gnome users :)

  /srv
  This doesn't even have a good rationale in the HFS, what exectly
  is this supposed to be, I think every *BSD Admin expects to find
  data for or from services provided by the system inside /var

  So the above things do not make sense in the general case, and
  as for the rest of the document, you can easly state that OpenBSD
  is atleast partially compliant!

Unfortunetly, i don't think the HFS is relevant to current or
future developments of OpenBSD; Atleast not in it's current state.

But I think the document is intresting, and maybe I'll butt in and
offer some of my opinions :)

Oh! And I almost forgot, we already have our very own HFS, it's
in hier(7) :-)

regards, thib.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Ingo Schwarze
In reply to this post by Jeff Licquia
Hi Jeff,

Jeff Licquia wrote on Mon, May 09, 2011 at 11:33:27PM -0400:

> (Sorry if this isn't the proper list for this discussion.  If not,
> please point me in the right direction.)

Since your enquiry is not backed up by a patch proposing specific
changes to the OpenBSD operating system, this will hardly be
considered a technical discussion round here, so <[hidden email]>
might have been more apropriate.  On the other hand, i see that
thib@ considers tech@ fine, so it may be an edge case.
Most importantly, do *not* cross-post.

> The Linux Foundation's LSB workgroup has taken over maintenance of
> the Filesystem Hierarchy Standard, and is working on a number of
> updates needed since its last release in 2004.
>
> Despite all the "Linux" in the names above, we're wanting to make
> sure that the FHS remains independent of any particular UNIX
> implementation, and continues to be useful to non-Linux UNIXes.

I have briefly looked through it and found the following things
you might wish to consider, if - as a first step - you want to make
the FHS more accurately describe reality in more operating systems,
in particular including OpenBSD:

 - Consider changing /boot to optional.  Our boot loader does
   not require any additional files, and i guess many people
   round here would consider one that does as excessive complexity.
 - Consider changing /lib to optional.  In OpenBSD, we consider
   it as very important that all binaries outside /usr are
   statically linked on all architectures, in particular that
   none of the binaries in /bin and /sbin use the run-time linker.
   We also consider kernel modules more of a nuisance than an
   asset.  Thus, /lib would be pointless in OpenBSD.
 - Consider changing /media to optional.  We do not use it,
   and i cannot remeber anyone explaining a need for it round
   here.
 - Consider changing /opt, /etc/opt, and /var/opt to optional, and add
   a note that some UNIX systems are using other locations for the same
   purpose.  For example, OpenBSD is using /usr/local.
 - Consider changing /srv to optional.  We do not use it,
   and i cannot remeber anyone explaining a need for it round
   here.  For the web server, we use /var/www, for example.
 - Consider moving chown, mount, and umount to /sbin.  They are not
   user commands, but root-only commands for system administration.
 - Consider moving dmesg and mknod to /sbin.  Even though they are
   not root-only, they are mostly relevant for system administration
   and hardly ever for users.
 - Consider deleting false, more, sed, true, and uname from the list
   of required commands in /bin.  They are not fundamental commands
   and can happily reside in /usr/bin.
 - Please delete su from the list of required commands in /bin.
   Using it would be utterly pointless in single-user mode.
 - Consider deleting the requirement that gzip, gunzip, zcat, and
   netstat be in /bin.  They can happily live in /usr/bin.
 - Consider deleting the requirement that ping be in /bin.
   It can be considered a system administration tool and reside in /sbin.
 - Consider removing the restiction to use /mnt by the installer.
   The OpenBSD installer does use it, and i don't see any problem
   with that, nor any need for standardization: What is a portable
   installer?!
 - Consider allowing /fastboot as an alternative to /sbin/fastboot.
   Actually, the former is a more logical placement, as it is related
   to boot, not to system administration binaries.
 - Please remove getty from the list of programs required in
   /sbin.  It is not a utility at all, not used for system
   administration, and pointless in single-user mode.  In OpenBSD,
   it resides in /usr/libexec.
 - Consider removing the requirements for /usr/bin/X11, /usr/lib/X11,
   and /usr/include/X11.  If any system needs them, fine, let it
   use them, but i really don't see the point in requiring them
   everywhere.
 - Consider deleting python, tclsh, wish, and expect from the list
   of commands required to be in /usr/bin.  According to the rest
   of the FHS, they should be in /opt, and agreeing with that, we
   place them in /usr/local.
 - Consider deleting the requirement for /usr/lib/sendmail,
   it really seems obsolete by now.
 - Consider marking /usr/local/etc, /usr/local/games, and /usr/local/src
   as optional.  Some systems may use them, but i don't see a point
   in requiring them.
 - Consider allowing /usr/local/libdata, /usr/local/libexec, and
   /usr/local/info as optional directories.
 - Consider removing the requirement for /usr/local/share/man.
   /usr/local/man is required anyway, and that seems sufficient.
 - The requirements regarding the internal organization
   of /usr/share/man should be relaxed.  Look here:
     $ man -w cat troff
     /usr/share/man/cat1/cat.0
     /usr/local/man/man1/troff.1
   In particular, locale subdirs should not be required.
   Usually, translations are of inferior quality anyway,
   so i think the requirement to cope with translated manuals
   should be removed.
 - You might wish to add an optional "man9" for kernel manuals.
 - You should remove the requirement to append an X to the file
   names of X windows manuals.  File naming is out of scope for
   a document describing hierarchy layout, and not all systems
   use that suffix anyway.
 - Consider marking /var/lib, /var/local, and /var/lock as optional.
 - Consider allowing /usr/libdata for miscellaneous utility data files,
   in particular perl modules.  These do not belong under /usr/lib
   because they are not binaries, and they don't belong under share
   because part of them cannot be shared across systems.
 - Consider allowing /usr/libexec for system daemons and utilities
   executed by other programs.  This is the standard place for
   executable stuff that is not called interactively and must never
   be in the PATH.
 - Consider allowing /usr/obj to be a companion directory to /usr/src,
   as an architecture specific target tree.

That list is probably still incomplete, but i think it includes most of
the points where the FHS does not match OpenBSD.  I feel this list is
surprisingly short, and nearly all of the items are surprisingly
trivial.  So, it guess we are less far apart than some people seem
to think.

Several people talked about the ugliness of /lib64.  I do not
see any problem with that; it is optional.

Actually, i found at least one minor point we might learn from
the FHS:  We should consider moving /etc/magic to /usr/share/misc/magic.
It's in the base, not the etc set, so editing it by hand will quickly make
the admin unhappy anyway.

> My question to you is: do you consider the FHS to be relevant to
> current and future development of OpenBSD?

Not very much.  I suspect patches to OpenBSD following the single
purpose of making OpenBSD better conform to the FHS would be considered
"change for changes' sake" and hence rejected.  However, as shown by the
example of magic(5) above, the FHS might provide a few useful hints
here and there, where it agrees with what we want to do anyway.

If the FHS can be made less Linux-centric and if software maintainers
listen to it, that might also simplify porting software now and then,
but that are a lot of ifs, and i'm not a porter myself, so i'm not
sure whether file system layout issues are really that annoying in
porting practice to make any significant amount of work on the standard
worthwhile.

Personally, i'm interested in documentation (among other subjects),
and i tend to regard hier(7) and the FHS mostly as documentation
projects.  However, directory layout is a relatively minor issue in the
field of documentation and i will hardly focus on it - but maybe provide
some feedback now and then.

> If not, is this simply due to lack of maintenance; would your interest
> in the FHS be greater with more consistent updates?
>
> If you are interested, consider this an invitation to participate.
> We've set up a mailing list, Web site, etc., and are reviving the
> old bug tracker.

Uh oh, starting a "project" by setting up a web site and a mailing list
is generally regarded with lots of suspicion round here.  ;-)

>  More details can be found here:
>
> http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

I fear opening tickets for all of the above would cause an
awful amount of work.  Any better ideas how to handle this?

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Jeff Licquia
On 05/10/2011 09:18 AM, Ingo Schwarze wrote:
> I fear opening tickets for all of the above would cause an
> awful amount of work.  Any better ideas how to handle this?

I can scan it and turn it into bugs.  I'm probably more familiar with
what might be duplicates, so it probably makes more sense for me to do it.

Thanks, by the way, for the critique; it's really useful.

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Amit Kulkarni-5
In reply to this post by Ian McWilliam-2
> system32 <- 64 bit dll + apps
> sysWOW <- 32 bit dll + apps
>
> How's that for backwards compatibility.
>

That's utterly ridiculous. The guy responsible for such things should
be fired :)

Reply | Threaded
Open this post in threaded view
|

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

Marco Peereboom
On Tue, May 10, 2011 at 12:33:15PM -0500, Amit Kulkarni wrote:
> > system32 <- 64 bit dll + apps
> > sysWOW <- 32 bit dll + apps
> >
> > How's that for backwards compatibility.
> >
>
> That's utterly ridiculous. The guy responsible for such things should
> be fired :)

It works and the users don't know it did.  Why does he have to be fired?

Compare that to the Linux model.