DaemonForums  

Go Back   DaemonForums > Miscellaneous > Off-Topic

Off-Topic Everything else.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 5th April 2011
Mr-Biscuit Mr-Biscuit is offline
Banned
 
Join Date: May 2008
Posts: 272
Default A new thread on which compatibility layers are or aren't useful.

I wouldn't mind there being a complete compatibility with sparc64 and powerpc between:
openbsd and freebsd
openbsd and netbsd
netbsd and freebsd.

I've asked on the freebsd mailing list about linux compatibility for the ppc architecture- this would be good on some low end machines- and learned that they are working on such.

Okay, so what's your opinion on what compat layer has value?
Reply With Quote
  #2   (View Single Post)  
Old 6th April 2011
Mr-Biscuit Mr-Biscuit is offline
Banned
 
Join Date: May 2008
Posts: 272
Default

This post has been altered. I was feeling bad but now I am not.

Last edited by Mr-Biscuit; 6th April 2011 at 04:33 AM.
Reply With Quote
  #3   (View Single Post)  
Old 6th April 2011
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

You're not the only person that has problems, you're seeing conspiracy where there isn't one.

The binary compatibility layers were quite important at one point, but a lot of stuff has open source replacements.. Netscape was once distributed as a Linux/BSDI-only binary at one point.

They do not support emulating binaries from other architectures, the compatibility layers consist only of system call translations.. ABI compatibility.

As for your impatience, someone else will respond when they have something to say.

Take care of yourself.
Reply With Quote
  #4   (View Single Post)  
Old 6th April 2011
Mr-Biscuit Mr-Biscuit is offline
Banned
 
Join Date: May 2008
Posts: 272
Default

I know that. Unfortunately, I have to explain myself at times.
Thanks.

It seems that NetBSD has the most compatibility options.
Reply With Quote
  #5   (View Single Post)  
Old 6th April 2011
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by Mr-Biscuit View Post
I wouldn't mind there being a complete compatibility with sparc64 and powerpc between:
openbsd and freebsd
openbsd and netbsd
netbsd and freebsd.
With respect to OpenBSD, this is further complicated by the fact that FFS is not the same across all architectures, & the project does not guarantee such compatibility (although there is some compatibility for a limited number of platforms...). As for a couple of issues:
  • consider the byte-ordering expected by the processor.
  • sparc64 expects partitions to begin/end on cylinder boundaries. Most other architectures don't.
One can see from this limited list of factors that this emerging matrix (OpenBSD/sparc64 -- FreeBSD/i386, OpenBSD/i386 -- FreeBSD/sparc64, etc.) becomes unwieldy very fast. And with the OpenBSD project, is there a developer who finds this interesting enough to write, test, & maintain it? Of course, the OpenBSD project is also very open to code submissions, but they also do not hesitate applying the same quality level expectations they expect from themselves.

Last edited by ocicat; 6th April 2011 at 01:37 AM.
Reply With Quote
  #6   (View Single Post)  
Old 6th April 2011
Mr-Biscuit Mr-Biscuit is offline
Banned
 
Join Date: May 2008
Posts: 272
Default

Yeah, I get that from FreeBSD at times also.
"Blah blah blah didn't end on cylinder boundary." Happened when I used an Ubuntu PPC disk to partition the G4.
Something that OpenBSD has over FreeBSD are more supported architectures.
Reply With Quote
  #7   (View Single Post)  
Old 9th April 2011
thirdm thirdm is offline
Spam Deminer
 
Join Date: May 2009
Posts: 248
Default

I never use compatibility layers for anything, so sorry if I'm unsympathetic.

I think effort spent on compatibility layers or effort to keep something like ffs compatible between forked BSD projects is wasted effort. It's the sort of thing you'd need to be paying developers for and more than that would have it be part of their job requirements that they maintain such an interface across every release with a formal QA organization checking up on them. Since the other projects you'd be maintaining compatibility with are changing too, it would be a frustrating requirement even if you were being paid and had organizational support.

For a project like OpenBSD, it's completely the right thing in my opinion for them to throw away these compatibility layers whenever they want and to tell users in clear terms that they shouldn't expect to use FFS filesystems or disklabels from other BSDs under OpenBSD and expect it to work.

Furthermore, this is a case where giving a patch isn't enough, you (and some other people?) would have to be in it for the long haul. If you give them a patch to keep up some small part of the compatibility layer, what should they do with it? They could take it and hope that more patches will come so that they'll more or less keep something sort of working. Or they could say to themselves that they don't like offering half-working flaky solutions that aren't long term sustainable and suggest that anyone wanting such a compatibility layer gather their own project together with other interested parties and maintain it themselves outside the main tree. If I were doing an OS, I'd at most offer some simple mechanism that redirects system calls so that the layers could be done as userland libraries and suggest anyone wanting such a thing start something up on github or whatever their preferred place for putting their code is. It's the sort of thing that ought to be in the ports system, not in the main tree.

Seems to me in this they're actually less idealistic and purist in how they've approached it since some of these layers still exist. I guess some of their developers must have used them for something once upon a time or use them now.
Reply With Quote
  #8   (View Single Post)  
Old 9th April 2011
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by thirdm View Post
I guess some of their developers must have used them for something once upon a time or use them now.
There was a time when the number of applications in OpenBSD's ports tree would have been called anemic, so offering compatibility was a way users could run common applications found on other platforms, but the ports tree has substantially filled out in the last few years, so maintaining compatibility no longer has the need it did at an earlier age.

The other aspect not mentioned in this thread (I failed to stress this explicitly enough in my earlier response...) is that the OpenBSD project does not let user requests determine either policy or direction without accompanying code submissions. Pleas for feature requests without code are simply ignored. It is important to understand that the target audience of the OpenBSD project is the project developers themselves. The rest of us merely benefit from their work, but we have no say in how the project is managed. Those interested in OpenBSD should take the time to familiarize themselves with the project's goals publicly stated at the following:

http://www.openbsd.org/goals.html
Reply With Quote
Reply

Tags
i'm telling the truth, we were told to start a new thread

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
compatibility layers BSDfan666 OpenBSD General 7 6th April 2011 02:17 AM
Urtw driver compatibility question Alex_Dc OpenBSD General 14 13th February 2010 11:31 PM
Quality and Backwards Compatibility of GNU Tools ... vermaden Off-Topic 1 12th May 2009 08:25 PM
Bug-For-Bug Compatibility JMJ_coder General software and network 2 12th September 2008 07:03 AM
I need help fixing Linux compatibility problems. troberts FreeBSD General 1 14th May 2008 04:26 PM


All times are GMT. The time now is 11:01 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick