|
General software and network General OS-independent software and network questions, X11, MTA, routing, etc. |
|
Thread Tools | Display Modes |
|
||||
@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 |
|
||||
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. |
|
||||
Quote:
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. |
|
||||
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''. |
|
||||
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 |
|
||||
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). |
|
|||
Quote:
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. |
|
||||
Quote:
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. |
|
|||
Quote:
|
|
||||
Quote:
|
|
||||
Quote:
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. 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. |
|
||||
@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 :-) |
|
|||||
Quote:
Quote:
Quote:
Quote:
Quote:
|
|
||||
Quote:
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:
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. |
|
|||
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 |
|
||||
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:
|
|
||||
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/ |
|
||||
Quote:
Oko, J65nko and jggimi, thanks for the info on Xenocara, I'll have a look at the links. |
|
||||
Quote:
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 |
|
|
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 |