DaemonForums  

Go Back   DaemonForums > Miscellaneous > General software and network

General software and network General OS-independent software and network questions, X11, MTA, routing, etc.

Reply
 
Thread Tools Display Modes
Old 26th May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

@Oko

So NetBSD x11 sets that you can select during install will install in the same /usr/pkg/* PATH as the one built from pkgsrc? (I started to interest in NetBSD recently so I lack knowledge here)
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
Old 26th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by vermaden View Post
@Oko

So NetBSD x11 sets that you can select during install will install in the same /usr/pkg/* PATH as the one built from pkgsrc? (I started to interest in NetBSD recently so I lack knowledge here)
I believe so but I have not played with 5.0 yet Last time I played with NetBSD was 4.0 around Christmas last year while visiting my mother in law. I was bored. I use only OpenBSD on my production machines. Ask SoXXX with PP mail. He is a hardcore NetBSD user.
Reply With Quote
Old 26th May 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Default

Well, I might sound like a jerk, but I think I will open my mouth.


In my opinion, if you're not working on X.Org, then shut up -- whining or bitching about a program rarely makes it better. Unlike *some* things that may irk you, X.Org for the most part has source code available. Don't like it, then hack on it, or pay someone to hack on it for you, and if that is still not good enough, shove off to another program or put up with it.

Running a computer is *not* a democracy! That is why we have a kernel in charge and more general forms of control in place above it . If software was democratic there would be no client/server architectures, only peer to peer. It is the X.Org folk who have a right to say in what way things go with /their/ implementation of it. If they wanted to do so, they could say fuck you all: we will only support the Amiga 500 !!!


That is how I feel about listening to this discourse, and just about every discussion of its nature.



The only time I had to modify xorg.conf because of an update was to get my mouse cursor working again; after learning about the 3 fingered salutes being defaulted off, I was annoyed that I never heard about it until afterwards because it can be handy in a pinch, but also aligned myself to the idea, that it should probably have been defaulted as it is now, 20 years ago. Not my project, not my say.


For portability, what can be expected of it?


Portable code can be written in any language, and in my experience there is no portable high level language with more non-portable code written in it then there is with C. Standard C is the most portable anything that I have ever seen: and as much pain as it can be to live with, since doing _anything fun_ in C, is essentially non portable in comparison to the language standard itself! I also commend the insane level of meticulous thought that must have went into standardizing C, which is also probably one of the least 'standardized' languages in use...

No matter what you go, what you do, something like X.Org will be either NON PORTABLE or NON FUN. The question is how much of it has to be that bitch to port along for the ride.


If you don't believe me, just look at C99 and tell me where I can find a standard library function emulating FreeBSD system call number 136 on any platform, even ones that don't guarantee a hard drive!



The thing that I wonder, is *how* much of X.Org must be ported to be useful. Do we have to port each driver to the kernel, do we have to port some library, do we have to port every single part of the X server? Dealing with the innards of graphics cards is pretty damn unportable stuff in its own right, let along dealing with kernel specifics, unless you want to standardize both, in which case you would likely have to end up with something half as portable as standard C or as portable as sound APIs (or if you like, as portable as x86 sepcifics), and about as useful as Dartmouth BASIC from the 1960s on modern computers!


I know what I would like to see, from the perspective of a programmer: drivers that use as few bits of the native kernel directly, and instead utilizes code that glues the relevant features of the system into the X Windows System at the appropriate levels where they are needed: so you don't have to directly port every single driver to each kernel, anymore then you should technically have to port xeyes to each X11 implementation. And I would actually consider it an unfortunate design decision if X.Org didn't do this at some level of hardware access, at least for the PC architecture.


But as I don't write the code and as I don't have the skill nor the time to acquire it, nor the bearded mentor to iron it into me, I leave X.Org to being X.Org, and accept it for what it is: a massive body of code that I could never do myself -- short of spending a couple of life times doing it. And also as a body of software that in the long run, makes my life more easier then it does harder.



If this offends anyone or requires moderation, sorry !
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.

Last edited by TerryP; 26th May 2009 at 05:20 AM.
Reply With Quote
Old 26th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by TerryP View Post


If you don't believe me, just look at C99 and tell me where I can find a standard library function emulating FreeBSD system call number 136 on any platform, even ones that don't guarantee a hard drive!
BSDisms are no better than Linuxisms. Who cares for FreeBSD system call
number 136. You should avoid using system calls by all means if possible. If you must make system calls in particularly FreeBSD specific isolate them in
an api so that the one who is trying to compile the software on other OS can rewrite that small part.

And by the way DragonFly is a living proof that C99 standard can be implemented. There is not a single line of a code in DragonFly which is not C99. OpenBSD as well is almost clean of non C99 code.
Reply With Quote
Old 26th May 2009
TerryP's Avatar
TerryP TerryP is offline
Arp Constable
 
Join Date: May 2008
Location: USofA
Posts: 1,547
Default

FreeBSD system call number 136 is the one for int mkdir(const char *, mode_t); which is a UNIXism, or more likely an 'ism from whoever they stole it form and eventually adapted to C lol. I chose to refer to it like that, as an example (and curious if anyone would look it up and see it crystal clear).


My point being. mkdir() is an OS specific system call -- both its presence, system call number, calling convention, behaviour, and above all..... What says that your code is running on a computer that has access to a file system in the first place, let along that said file system must implement the directories concept at all ;-). Directories/Folders are a universally simple and in the modern world, very a portable concept. Actually doing anything fun with them is non portable, and likely to be extremely so if you want to write portable code - because it might just find itself on a directory less file system, let along a mkdir()'less environment. This is why perl mkdir() or python os.mkdir() are fairly portable for unix/windows/most os, but doing it in C is not as much fun.


Now if something that simple is inherently non-portable, can anyone really expect implementing something as complex as X11R7 to be? Especially when you consider that while old mkdir() will be there in any Unix C API (and standardized), so it might not sound like a big deal: but can the same be said of accessing display or graphics hardware through system APIs? POSIX doesn't get into a lot of that stuff because it is outside the intended scope, much like what is needed to write a screen saver is beyond the scope of C99s need to be portable. You can write a screen saver that is valid C99 code, but you writing a portable screen saver is a bit harder



Before starting work on my star fighter game, I needed to solve very non portable issues -> graphics, keyboard/mouse, and audio access. Now it is fair to say, you must have a mouse or a keyboard to use my game, but it is fair to say: you must have the same mouse I do, since I don't care to write code for yours? As your statement (which I very very highly agree with Oko) might suggest, for me the only viable solution was to use a portable interface as much as possible, and make that the requirement rather then something very specific to the system. For me the choice was a no brainer named SDL. If SDL don't work well enough for someones needs, well that's not my problemo... hehe .
__________________
My Journal

Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
Reply With Quote
Old 26th May 2009
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by TerryP View Post
In my opinion, if you're not working on X.Org, then shut up -- whining or bitching about a program rarely makes it better.
I may understand that kind of attitude when it comes to Operating System choice, there are multiple choices here, Windows, Mac OS, Linux, many BSD, OpenSolaris, many less populat systems like Syllable or ReactOS, but when it comes to x11 what you have as an alternative? XFree86 you say, but how many ports will fail and/or require Xorg as a dependency, generally much more hassle/work to do the same thing.
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
Old 26th May 2009
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

A couple of orthogonal (but not new) thoughts for the conversation.

A) The complaints related to Xorg in this thread seem to be symptomatic of difficulties BSD has in general. Viz, not enough manpower to truly "roll your own," inability to induce desired support/"mindspace" from outside software/hardware developers, etc. ISTM one of the root causes of this is fragmentation of the BSD family, resulting in resources wasted on duplicate effort and lack of critical mass for each project. And why are the BSD's fragmented? Well, I guess a variety of reasons, but Linux hippies / fanboys / crowds / -isms aren't one of them .

B) Regarding X, what about the console framebuffer (my fave topic ), couldn't better use be made of that? This is one area where Linux is ahead of BSD, but how hard would it really be to catch up or better? That is, create butt-kick graphic-mode virtual consoles that are robust, flexible, easy to configure and support acceleration. This would have many benefits:

- much better console;

- encourage development of apps that can run on framebuffer -- some are already there: mplayer, links, picture viewers, etc., but it's still too rudimentary.

- makes X less essential (but not entirely so for most users);

- when X is needed, simply run it on framebuffer on another VC. This is already possible (with fbdev) but needs better seamlessness and acceleration for example. You might not be able to switch modes, but we lost that with Xorg already (and I don't miss it much).
Reply With Quote
Old 26th May 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Banned
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Default

Quote:
Originally Posted by TerryP View Post
My point being. mkdir() is an OS specific system call -- both its presence, system call number, calling convention, behaviour, and above all..... What says that your code is running on a computer that has access to a file system in the first place, let along that said file system must implement the directories concept at all ;-). Directories/Folders are a universally simple and in the modern world, very a portable concept. Actually doing anything fun with them is non portable, and likely to be extremely so if you want to write portable code - because it might just find itself on a directory less file system, let along a mkdir()'less environment. This is why perl mkdir() or python os.mkdir() are fairly portable for unix/windows/most os, but doing it in C is not as much fun.
No system calls are standardized, they different between all operating systems.. that's why a common set of high level libraries are provided that comply with standards.

mkdir(2) on OpenBSD is just a wrapper to the mkdir system call.. but it doesn't have to be, mkdir(2) is now standardized.. how it works behind the scenes is implementation specific, it could call upon the cosmic forces to align the stars in a way that represents a new hierarchal level. (..if you were crazy enough to mess around with such dangerous yet imaginary forces.)

http://www.opengroup.org/onlinepubs/...ons/mkdir.html

If the operating system you're attempting to port to has no concept of a file system, it will be extremely hard for them to be POSIX/SUS compliant..

In the end it depends on your definition of portable, can you write a game that works on every OS in existence? probably not.. it wouldn't be incredibly useful on the embedded trimmed down OS on a craft orbiting Pluto, so consider limiting your target to a specific type of operating system.. many exist that have similar environments and share a common set of operations.

Xorg is a reference implementation of X11 for POSIX compatible systems, but sometimes 3rd parties painstakingly try to port it to non-POSIX systems.

Last edited by BSDfan666; 26th May 2009 at 02:47 PM.
Reply With Quote
Old 26th May 2009
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Quote:
Originally Posted by TerryP View Post
The thing that I wonder, is *how* much of X.Org must be ported to be useful. Do we have to port each driver to the kernel, do we have to port some library, do we have to port every single part of the X server?
X graphics drivers run in userspace. The entire X graphics stack runs in userspace. That's one of the beauties of X.

There's a tiny fraction of the DRI/DRM infrastructure that runs in the kernel for hardware 3D acceleration. Accelerated 2D can all be done in userspace, as is software 3D. That's what makes it so portable.

And that's what Xorg seems hell-bent on breaking.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 26th May 2009
adamk adamk is offline
Spam Deminer
 
Join Date: May 2008
Posts: 250
Default

Quote:
Originally Posted by phoenix View Post
X graphics drivers run in userspace. The entire X graphics stack runs in userspace. That's one of the beauties of X.

There's a tiny fraction of the DRI/DRM infrastructure that runs in the kernel for hardware 3D acceleration. Accelerated 2D can all be done in userspace, as is software 3D. That's what makes it so portable.

And that's what Xorg seems hell-bent on breaking.
It's not quite that simple, unfortunately. I can't speak to the intel drivers and GPUs, but newer radeon cards (r500 and up) don't even have 2D hardware any more. Somewhat decent performance can be achieved with shadowfb, but good 2D performance requires using the 3D engine.... Which requires DRI/DRM.
Reply With Quote
Old 26th May 2009
ephemera's Avatar
ephemera ephemera is offline
Knuth's homeboy
 
Join Date: Apr 2008
Posts: 537
Default

Quote:
Originally Posted by adamk View Post
It's not quite that simple, unfortunately. I can't speak to the intel drivers and GPUs, but newer radeon cards (r500 and up) don't even have 2D hardware any more. Somewhat decent performance can be achieved with shadowfb, but good 2D performance requires using the 3D engine.... Which requires DRI/DRM.
Interesting.
Reply With Quote
Old 26th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by IdOp View Post
A couple of orthogonal (but not new) thoughts for the conversation.

A) The complaints related to Xorg in this thread seem to be symptomatic of difficulties BSD has in general. Viz, not enough manpower to truly "roll your own," inability to induce desired support/"mindspace" from outside software/hardware developers, etc. ISTM one of the root causes of this is fragmentation of the BSD family, resulting in resources wasted on duplicate effort and lack of critical mass for each project. And why are the BSD's fragmented? Well, I guess a variety of reasons, but Linux hippies / fanboys / crowds / -isms aren't one of them .
Your answer is typical of Linux hippies / fanboys / crowds / who
lack the historical prospective. X Window system has nothing to do with
Linux. it is developed almost 10 years before Linus wrote a first line of
code on his "new operating system". The project has been hijacked by
so called Linux community (which is code word for industry proxies) which
wants completely to control all technologies. Another less irritating
example is GCC compiler and its development. It is another example of
Linux is everything which is not Windows attitude.

BSDs are not fragmented. There are only four BSD project each one with the very specific set of goals.

Linux is also not fragmented. There is only one large enterprise industry backed Linux (RedHat) and two smaller new
vendors Novel (SuSE) and Canonical (Ubuntu). All others are kidding themselves if they thing that they are actually developing Linux. Putting things together and making installation scripts (Debian apt) is not the same as developing an operating system.

For the record DragonFly and NetBSD use the same packaging system. It is hard to compare four academic/volunteering projects with a large commercial enterprise as Linux which has industry
giants behind it (IBM, HP, RedHat). Linux hippies / fanboys / crowds /
might not be on the way of BSD development but industry is certainly uneasy when 100 people volunteering project (OpenBSD) makes a product
(OpenSSH) which has 80% of market share.



Quote:
Originally Posted by IdOp View Post
B) Regarding X, what about the console framebuffer (my fave topic ),
I can speak only of OpenBSD. Your question is so often asked that it is answered on FAQ. There is no interest (so far should I add) among developers for framebuffer. It is IMHO valid argument.
Reply With Quote
Old 26th May 2009
Oliver_H's Avatar
Oliver_H Oliver_H is offline
Real Name: Oliver Herold
UNIX lover
 
Join Date: May 2008
Location: Germany
Posts: 427
Default

@terryp

>In my opinion, if you're not working on X.Org, then shut up

This is to some degree a rather silly argument or should I say some kind of Raadtism a la 'shut up and code'? ;-)

Well as I said to some degree (e.g. in a *buntu desktop forum), but there are more ways to contribute to a FOSS project than just contributing some code. I started with UNIX in terms of Irix on a nice and shiny SGI workstation, back in the good old days. At home my first UNIX was some NetBSD on an Amiga, later Slack and so on. In contributed a lot: money, problem reports, help on mailinglists, help on LUGs/UUGs, sometimes I contributed some mirror (at university) etc. So this is worth nothing according to your saying? It's just the code? Well my boy, welcome in the reality - I'm one of the small supporters of OpenBSD for example that buys the CD sets, sometimes T-shirts too ... and I'm mainly a FreeBSD user. I do this because of the great work of those guys and sometimes I'm even 'whining' (in terms of 'I have a severe problem and I'm able to reproduce it or even debug it to some degree').
__________________
use UNIX or die :-)
Reply With Quote
Old 26th May 2009
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Originally Posted by Oko View Post
Your answer is typical of Linux hippies / fanboys /
crowds / who
lack the historical prospective. X Window system has nothing to do with
Linux. it is developed almost 10 years before Linus wrote a first line of
code on his "new operating system".
I am quite aware of this aspect of the history.

Quote:
The project has been hijacked by
so called Linux community (which is code word for industry proxies)
which
wants completely to control all technologies.
I don't disagree with that, and do understand the frustration associated with this state of affairs (though perhaps my post could have acknowleged that briefly). However, the point I was trying to make was related to the next items.

Quote:
BSDs are not fragmented. There are only four BSD project each
one with the very specific set of goals.
Obviously there is co-operation and exchange between them, which is good, but still you have different kernels (at the heart of what I meant by fragmented). If things were more unified (in principle) wouldn't that (a) free up developer resources for many purposes, (b) improve the chances of outside developers contributing optional-use products; (c) cause the whole to add up to more than the currents parts do? (Not that things will unite, but that is my perception of the situation.)

Quote:
Linux is also not fragmented.
I would say Linux is definitely fragmented (perhaps moreso) at the packaging level, but it's all the same kernel. Wouldn't that make it easier for 3rd parties to support (depending on the application)?

Quote:
I can speak only of OpenBSD. Your question is so often asked that it is answered on FAQ. There is no interest (so far should I add) among developers for framebuffer. It is IMHO valid argument.
According to another post on this forum, there has been some unreleased (not sure if that's the right term) code in the tree for this. That's just the kind of thing I have in mind that could benefit from reducing duplication and freeing developer resources. Another example is Xenocara. If they had more resources, perhaps they wouldn't have to start with Xorg (bastard son of Linux ) and could start more from scratch (XFree?). I don't know any of the history of Xenocara, so just take that example as a loose general idea.
Reply With Quote
Old 26th May 2009
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by IdOp View Post


Obviously there is co-operation and exchange between them, which is good, but still you have different kernels (at the heart of what I meant by fragmented). If things were more unified (in principle) wouldn't that (a) free up developer resources for many purposes, (b) improve the chances of outside developers contributing optional-use products; (c) cause the whole to add up to more than the currents parts do? (Not that things will unite, but that is my perception of the situation.)
The set of goals which they outlined for themselves can NOT be accomplished with the same kernel. There is not such thing as one shoe fits all feet. That is exactly what is wrong with Linux. It is trying to be everything track( server), a sedan (desktop) a spaceship (supper computer) and minimalistic OS (race care) and security app and
embedded OS. It is as simple as that. FreeBSD could adopt NetBSD packaging system and that would definitely free resources and that is all. OpenBSD can not adopt pkgsrc due to security issues.








Quote:
Originally Posted by IdOp View Post
Another example is Xenocara. If they had more resources, perhaps they wouldn't have to start with Xorg (bastard son of Linux ) and could start more from scratch (XFree?). I don't know any of the history of Xenocara, so just take that example as a loose general idea.
Demise of XFree86 is caused by license change which was not free enough.
OpenBSD is the freest operating system in existence which is going soon
to be free on any parts which are not academically licensed as BSD/MIT ect. So you gave a really bad example.

Xenocara could be theoretically totally separate from XOrg. That is huge job requiring many more developers. The secret of OpenBSD success
is the small group of very competent developers (less than 100) who
can effectively communicate and advance very narrow set of goals.

It is much more probably that OpenBSD would get a framebuffer support
and drop all together X than they will completely fork X.
Reply With Quote
Old 26th May 2009
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

About Xenocara :
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 26th May 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Quote:
Originally Posted by IdOp View Post
I don't know any of the history of Xenocara...
http://xenocara.org points to an OpenBSD Journal article, excerpted here as it is apropos to the topical discussion. Click on http://undeadly.org/cgi?action=artic...&mode=expanded if you want to see the entire article and the threaded discussion that followed.
Quote:
Originally Posted by Matthieu Herrb
...Based on the experiences of other software projects, it was decided to switch to a more modular organization of the project, with more or less independent components ( http://people.freedesktop.org/~daniels/exdctalk/ ). This new organization will allow drivers maintainers (or others) to make independent releases, whenever they are needed.

X.Org has decided that the best tools to manage the build of this new modularized source tree are the GNU auto-tools. They have an existing large user and developer base, and thus feel easier to use by the majority of developers. Being maintained outside of the X.Org project is supposed to lower the maintenance burden on the X developers which are now free to concentrate on their code. The gnome pkg-config tool is used to keep track of version dependencies between new modules.....
Reply With Quote
Old 26th May 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

I should add that while modularization may be a good thing, it has eliminated both release management and integration testing by X.Org. As has been pointed out, this is now the responsibility of any *nix project/product that wants to use it. Theo knocked this pretty hard in his recent talk on release management at AsiaBSD:
Slides: http://openbsd.rt.fm/papers/asiabsdc...e_engineering/
Video: http://www.youtube.com/watch?v=i7pkyDUX5uM
Reply With Quote
Old 26th May 2009
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Quote:
Originally Posted by Oko View Post
The set of goals which they outlined for themselves can NOT be accomplished with the same kernel. There is not such thing as one shoe fits all feet. That is exactly what is wrong with Linux. It is trying to be everything track( server), a sedan (desktop) a spaceship (supper computer) and minimalistic OS (race care) and security app and
embedded OS. It is as simple as that. FreeBSD could adopt NetBSD packaging system and that would definitely free resources and that is all. OpenBSD can not adopt pkgsrc due to security issues.
I think we are going off on a tangent here. I did not say having 4 BSDs is a "crappy" model; far from it, much excellent work has been done. But that doesn't mean, AFAICT, that the reality of 4 separate smaller projects (forget the term fragmentation, call it design diversity ) can not have some sort of drawbacks of the kind I outlined. My point there, which you seem to have missed, is that the choice to have separate smaller projects, and consequences of that, has nothing to do with Linux.

Oko, J65nko and jggimi, thanks for the info on Xenocara, I'll have a look at the links.
Reply With Quote
Old 26th May 2009
roddierod's Avatar
roddierod roddierod is offline
Real Name: Rod Person
VPN Cryptographer
 
Join Date: Apr 2008
Location: Pittsburgh, Pa
Posts: 437
Default

Quote:
Originally Posted by Oko View Post
Demise of XFree86 is caused by license change which was not free enough.
OpenBSD is the freest operating system in existence which is going soon
to be free on any parts which are not academically licensed as BSD/MIT ect.
After the last upgrade of Xorg and the problems I had, I went to the XFree site to see if it was still being developed. The last version 4.8 released in Dec 2008 says that the licenses are all MIT, X Consortium, or BSD,
http://www.xfree86.org/4.8.0/README2.html#2. I'm not versed in the X Consortium license so I not sure about it's freedom.

I was thinking of playing around with it but got busy with other stuff...
__________________
"The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words." -Philip K. Dick
Reply With Quote
Reply

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
Installing Xorg NetBSD NetBSD Installation and Upgrading 20 9th June 2009 02:22 PM
Xorg installation LordZ OpenBSD Installation and Upgrading 10 23rd November 2008 05:52 PM
Is xorg necessary....... rex FreeBSD General 10 19th October 2008 03:05 PM
xorg bug? enterhaken FreeBSD Ports and Packages 9 17th July 2008 02:38 PM
Xorg sluggishness tanked FreeBSD Ports and Packages 2 17th May 2008 08:10 PM


All times are GMT. The time now is 06:18 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