You are so sure of things you don't understand but are still an AC... even if OpenStep in Mac OS X reuses the Toolbox, they are still two very different programming environments; Toolbox will never be able to take advantage of the intrinsic OO-ness and coherence of OpenStep. One thing is to take advantage of specific libraries; other thing is to build upon an extensible framework.
Nothing will be rewritten if OpenStep and Objective C prove to be of no advantage. But if they are what NeXT, Apple and GNUStep think they are, we should have a big advantage to native apps.
I now this is hypothetical. But Objective C has its advantages, and it's hard to dismiss the platform that gave us the HTML, HTTP and Lotus Improv.
The integration still isn't good... clipboard fails often, configuration is finicky, Win32 can't act as window manager to X apps. It's a kludge, a pain.
Just thought somewhat more about the issue -- yes, Carbon (Mac Toolbox) is permanent, but it is suboptimal; when applications arrive that make good use of Cocoa (OpenStep), there should be a natural selection favoring OpenStep (Cocoa) applications over (Mac Toolbox) Carbon ones. Besides, as users get more and more OpenStep applications they will note that Carbon ones, besides using up more resources, also load libraries that otherwise would be unnecessary. Also Mac OS X performance with Carbon will look bad compared to pure BSD and GNU/Linux -- so if the market isn't already corrupted by monopolies we should see a gradual, slow natural phasing away of Carbon.
Carbon API is just a bridge. The Cocoa applications are probably in testing now.
Re:Xfree is sufferring from poor PR
on
Xfree86 4.2.0 Out
·
· Score: 2
On one hand the question is not PR, but that Linus has had a much more open attitude than not only X people, but also than most GNU people -- even today Emacs development is pretty much done very discreetly. As X and GNU become more and more open, their visibility will also enhance, as people who today look only at the kernel realize they are actually more interested in X, glibc or Emacs.
On the other hand, the kernel has always been a glamourous topic... X with its own terminology and lots of borderline cases, besides reliance on pretty complex and sometimes even theoretical and statistical stuff is much less accessible. But this high-brown attitude in X is not absolute, and some X problems can be traced to initial pragmatism; also in Linux pragmatism has been the source of some problems, so it is probable that in time kernel development will be less accessible, aligning Linux with Emacs, Hurd or Lisp development.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
Just found this: http://www.xfree86.org/pipermail/render/2001-April/000965.html
Quoting Mark Vojkovich:
If the bandwidth issue is a concern we should discuss alternatives
to client-side rasterization, though I'm not sure there's much to
be gained by server-side rasterization. It could probably fit in
pretty well as option for the client to chose. At least I think
it could.
So they're thinking about it...
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
> I fucked up the terminology.
So did I.
I see your point -- the toolkit would be at the terminal, the X server. I thought there was a way of doing so already, may be wrong 'cause don't remember any specifics.
I wonder what the X core people would comment on this.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
I didn't quite got it yet. If you have a client installed at the host and the (non-hardware related) libraries are also there, what's the problem? The X server at the terminal should (IMHO) use them all right.
Obviously hardware-related extensions will still need to be at the client.
Re:Xfree is sufferring from poor PR
on
Xfree86 4.2.0 Out
·
· Score: 2
Pray, why X is an ugly protocol?
And I think Lisp is more elegant than Unix -- but that's an esthetical statement.
Re:Xfree is sufferring from poor PR
on
Xfree86 4.2.0 Out
·
· Score: 2
Technically and license-wise Linux is GNU, and GNU has adopted XFree... but this does not mean that XFree is GNU.
Do not judge thing with finances. Finances will pass away pretty soon, but technical and moral fundaments will take longer or just remain.
You didn't do your reading. GNUStep and Mac OS X Cocoa are both implementations of OpenStep whose first implementation was NeXTStep. Display GhostScript is an alternative implementation of Display PostScript, of which DisplayPDF is a subset plus derivative.
To sum it up, Adobe and Quark could already recompile their apps to any POSIX system using GNUStep.
> Imagine if you could not run a KDE app inside your GNOME desktop!
I meet this situation every day -- I can't run X clients in my (sadly) Windows desktop. I can run a X server in Windows, but Windows makes a good integration impossible.
Try not specifying ISO8859-15 in your Xdefaults, instead defining your LANG envirnoment variable as en_GB@euro or en_GB@iso885915 or whatever.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
Obviously you are so pragmatic you failed to do your bit of learning...
Have you any hard data to say your flickering X desktop wasn't misconfigured? Configuration is not tweaking, but most GNU/Linux distributions suck, and there aren't yet good autoconfigurators for dump people like you.
You fail to realize that the GUI not inconsistent, it is flexible -- if you install only Gnome, only GNUStep, or only FLTK apps you get a consistent desktop; the problem here is lack of enough well written applications, as most programming effort has been into either backend code or else wasted in forks and competitive efforts because of licensing or technical issues. But here X and POSIX are a good foundation, what still is missing is a popular enough GUI side combination of widgets, window manager and applications.
Drivers are there for performance and cleannes, and so are they there in Linux and BSD. Freezing drivers interfaces for too long creates cruft.
Keyboardability is arriving, at least in Gnome.
As for NeXT, have you heard of GNUStep?
Finally, I didn't quite got your COM rant... if you want things in the server, X terminals to you!
Why? Is POSIX inefficient or not flexible enough? Instead, such efforts tend to be less flexible than POSIX, and not so much more efficient -- BeOS, Mac OS X, Windows, whatever.
You are ill informed. Lack of network transparency is one of the reasons why all system administrators love X and hate Windows and the Mac.
pcAnywhere and Timbuktu are hacks, X is the real thing.
But the sum of the history is that client-server was a mistake, terminal-host still works better and with the free software resurgence, Java, Windows Terminal Services and thin clients, it is returning in full force. Terminal-host is cheaper, faster, more manageable and easier to upgrade than client-server.
New programming environment is also there already -- and alternatives too: the GNU standard is GTK++, if you thing C++ is the ultimate truth you choose Qt, if you're into Objective C or Mac compatibility you have GNUStep... I only miss a Lisp or Scheme alternative, but it's probably I who didn't look hard enough. If you are thinking imaging, then there's Display GhostScript, DisplayPDF and Display PostScript.
And what makes you think it is bad and inefficient?
It is no backwards compatibility cruft -- there is a core API and architecture, and extensions; any part besides the core (which is clean and efficient) can be substituted, and even the core can be rewritten for efficiency if you like.
Why move away from X? All the features you cited are available, our could be, to X thru extensions or rewritings -- except for user interface, which is out of scope of X.
In other words, what you want is just a X + extensions + wm + destop environment combination.
OK, would you care to give the URL to the start of the discussion?
Anyway I judge mailing lists and newsgroups just as I judge newspapers, by their treatment of issues I know. Usually they are pretty weak on databases and system administration, instead focusing on the latest, fastest, and fadest. Usually they are as chronologically snobish as the rest of our culture, sposing OODBs, OO programming and Red Hat alike against the sounder RDBMS, functional programming and Debian.
This was never intended to be a dissertation, but as an answer, I think you haven't read or experimented enough.
Darwin is bloated, yes. It needs 96MB to perform, and it's pretty monolithic.
This is not Linux conventional wisdom, in fact Linus believes in monolithic systems -- that's a factor in the current inadaptable, hard-to-change, hard-to -test situation. Do yourself a favor and look for the famous exchange between Linus Torvalds and Professor Tannenbaun (is this the name?) of OS design and Minix fame.
Darwin is a kind of half-baked microkernel, because it is integrated with a single server. So it has the performance problems, isn't compatible with other BSDs drivers, and looses flexibility. Besides, Apple and its users aren't really interested in flexibility.
Linux hope can't be in Hurd, because Hurd and Linux are mutually exclusive, Linux having being created because Hurd was taking too long. Go see Linus' announcements in Linux start of life. Rather, Hurd is a hope for the GNU Project and the free software community, especially that part of it that believes in copyleft and has lost hope in monolithic kernels. Meanwhile Linux was created out the GNU Project, while having a symbiotic relationship to it and depending on it; Linus believes in copyleft but not strictly; and he's more aligned to Open Source than to Free Software.
And Hurd has a chance at viability because of the microkernel plus multiple servers architecture inherent flexibility. So it could theoretically scale from small to big systems, and each configuration needn't include anything non-funcional or ill-suited.
Now remember that the whole point of microkernels is to enable flexibility -- not only for development's sake but also to be able to adapt to different loads and usage characteristics.
So the HURD seems to be the answer. That or Linus (or someone else, or a group of kernel hackers) over a reasonable amount of time manages to get better at (1) understanding modifications to Linux and their consequences and (2) based on this understanding only release "stable" kernels once they're done.
Given the complexity of the task, I doubt it's doable. The free flavours of BSD never scaled as far as GNU/Linux; the proprietay Unices have basically choosen to scale up and up, forgetting the small systems situations and accepting bloatedness in order to cater for stability, resilience and other high-iron stuff. Even single-server microkernels like Windows NT and Apple Darwin haven't much to offer, being bloated, slow and not flexible at all.
We still have a free software and open systems advantage, because POSIX OSs can cover the whole gamut of computing systems simply by having different kernels with the same APIs; standard bodies and GNU libc are the real heros here, not Linux or BSD. Proprietary software usually will be even more fragmented, with all those slightly incompatible, underperforming, unstable versions of Microsoft Windows, Mac OS Classic and so on. But still it would be nice to have a free, copylefted common kernel. Unless the Linux situation improves dramatically soon, the only answer in the horizon is the Hurd -- and it still needs to be finished.
Slashdot Mirror
You are so sure of things you don't understand but are still an AC... even if OpenStep in Mac OS X reuses the Toolbox, they are still two very different programming environments; Toolbox will never be able to take advantage of the intrinsic OO-ness and coherence of OpenStep. One thing is to take advantage of specific libraries; other thing is to build upon an extensible framework.
Nothing will be rewritten if OpenStep and Objective C prove to be of no advantage. But if they are what NeXT, Apple and GNUStep think they are, we should have a big advantage to native apps.
I now this is hypothetical. But Objective C has its advantages, and it's hard to dismiss the platform that gave us the HTML, HTTP and Lotus Improv.
The integration still isn't good... clipboard fails often, configuration is finicky, Win32 can't act as window manager to X apps. It's a kludge, a pain.
Just thought somewhat more about the issue -- yes, Carbon (Mac Toolbox) is permanent, but it is suboptimal; when applications arrive that make good use of Cocoa (OpenStep), there should be a natural selection favoring OpenStep (Cocoa) applications over (Mac Toolbox) Carbon ones. Besides, as users get more and more OpenStep applications they will note that Carbon ones, besides using up more resources, also load libraries that otherwise would be unnecessary. Also Mac OS X performance with Carbon will look bad compared to pure BSD and GNU/Linux -- so if the market isn't already corrupted by monopolies we should see a gradual, slow natural phasing away of Carbon.
You may be right, but I hope not. Big vendors sticking to Carbon and Win32 instead of porting to OpenStep (Cocoa) means less interoperability.
Anyway, these are proprietary vendors, and the GNU writing is on the wall.
GNUStep base is done already.
Carbon API is just a bridge. The Cocoa applications are probably in testing now.
On one hand the question is not PR, but that Linus has had a much more open attitude than not only X people, but also than most GNU people -- even today Emacs development is pretty much done very discreetly. As X and GNU become more and more open, their visibility will also enhance, as people who today look only at the kernel realize they are actually more interested in X, glibc or Emacs.
On the other hand, the kernel has always been a glamourous topic... X with its own terminology and lots of borderline cases, besides reliance on pretty complex and sometimes even theoretical and statistical stuff is much less accessible. But this high-brown attitude in X is not absolute, and some X problems can be traced to initial pragmatism; also in Linux pragmatism has been the source of some problems, so it is probable that in time kernel development will be less accessible, aligning Linux with Emacs, Hurd or Lisp development.
Just found this: http://www.xfree86.org/pipermail/render/2001-April /000965.html
Quoting Mark Vojkovich:
If the bandwidth issue is a concern we should discuss alternatives
to client-side rasterization, though I'm not sure there's much to
be gained by server-side rasterization. It could probably fit in
pretty well as option for the client to chose. At least I think
it could.
So they're thinking about it...
> I fucked up the terminology.
So did I.
I see your point -- the toolkit would be at the terminal, the X server. I thought there was a way of doing so already, may be wrong 'cause don't remember any specifics.
I wonder what the X core people would comment on this.
I didn't quite got it yet. If you have a client installed at the host and the (non-hardware related) libraries are also there, what's the problem? The X server at the terminal should (IMHO) use them all right.
Obviously hardware-related extensions will still need to be at the client.
Pray, why X is an ugly protocol?
And I think Lisp is more elegant than Unix -- but that's an esthetical statement.
Technically and license-wise Linux is GNU, and GNU has adopted XFree... but this does not mean that XFree is GNU.
Do not judge thing with finances. Finances will pass away pretty soon, but technical and moral fundaments will take longer or just remain.
You didn't do your reading. GNUStep and Mac OS X Cocoa are both implementations of OpenStep whose first implementation was NeXTStep. Display GhostScript is an alternative implementation of Display PostScript, of which DisplayPDF is a subset plus derivative.
To sum it up, Adobe and Quark could already recompile their apps to any POSIX system using GNUStep.
Please check http://gnustep.org./
> Imagine if you could not run a KDE app inside your GNOME desktop!
I meet this situation every day -- I can't run X clients in my (sadly) Windows desktop. I can run a X server in Windows, but Windows makes a good integration impossible.
Try not specifying ISO8859-15 in your Xdefaults, instead defining your LANG envirnoment variable as en_GB@euro or en_GB@iso885915 or whatever.
Obviously you are so pragmatic you failed to do your bit of learning...
Have you any hard data to say your flickering X desktop wasn't misconfigured? Configuration is not tweaking, but most GNU/Linux distributions suck, and there aren't yet good autoconfigurators for dump people like you.
You fail to realize that the GUI not inconsistent, it is flexible -- if you install only Gnome, only GNUStep, or only FLTK apps you get a consistent desktop; the problem here is lack of enough well written applications, as most programming effort has been into either backend code or else wasted in forks and competitive efforts because of licensing or technical issues. But here X and POSIX are a good foundation, what still is missing is a popular enough GUI side combination of widgets, window manager and applications.
Drivers are there for performance and cleannes, and so are they there in Linux and BSD. Freezing drivers interfaces for too long creates cruft.
Keyboardability is arriving, at least in Gnome.
As for NeXT, have you heard of GNUStep?
Finally, I didn't quite got your COM rant... if you want things in the server, X terminals to you!
Why? Is POSIX inefficient or not flexible enough? Instead, such efforts tend to be less flexible than POSIX, and not so much more efficient -- BeOS, Mac OS X, Windows, whatever.
XP has full transparency for individual clients or only Terminal Services desktop distribution?
You are ill informed. Lack of network transparency is one of the reasons why all system administrators love X and hate Windows and the Mac.
pcAnywhere and Timbuktu are hacks, X is the real thing.
But the sum of the history is that client-server was a mistake, terminal-host still works better and with the free software resurgence, Java, Windows Terminal Services and thin clients, it is returning in full force. Terminal-host is cheaper, faster, more manageable and easier to upgrade than client-server.
GNUStep with Display GhostScript and WindowMaker or a Gnome Aqua theme for you.
Don't forget GTK++ and the type servers. They are also helping here.
New programming environment is also there already -- and alternatives too: the GNU standard is GTK++, if you thing C++ is the ultimate truth you choose Qt, if you're into Objective C or Mac compatibility you have GNUStep... I only miss a Lisp or Scheme alternative, but it's probably I who didn't look hard enough. If you are thinking imaging, then there's Display GhostScript, DisplayPDF and Display PostScript.
And what makes you think it is bad and inefficient?
It is no backwards compatibility cruft -- there is a core API and architecture, and extensions; any part besides the core (which is clean and efficient) can be substituted, and even the core can be rewritten for efficiency if you like.
Color matching is also an extension.
Why move away from X? All the features you cited are available, our could be, to X thru extensions or rewritings -- except for user interface, which is out of scope of X.
In other words, what you want is just a X + extensions + wm + destop environment combination.
Please do your reading in the subject.
OK, would you care to give the URL to the start of the discussion?
Anyway I judge mailing lists and newsgroups just as I judge newspapers, by their treatment of issues I know. Usually they are pretty weak on databases and system administration, instead focusing on the latest, fastest, and fadest. Usually they are as chronologically snobish as the rest of our culture, sposing OODBs, OO programming and Red Hat alike against the sounder RDBMS, functional programming and Debian.
This was never intended to be a dissertation, but as an answer, I think you haven't read or experimented enough.
Darwin is bloated, yes. It needs 96MB to perform, and it's pretty monolithic.
This is not Linux conventional wisdom, in fact Linus believes in monolithic systems -- that's a factor in the current inadaptable, hard-to-change, hard-to -test situation. Do yourself a favor and look for the famous exchange between Linus Torvalds and Professor Tannenbaun (is this the name?) of OS design and Minix fame.
Darwin is a kind of half-baked microkernel, because it is integrated with a single server. So it has the performance problems, isn't compatible with other BSDs drivers, and looses flexibility. Besides, Apple and its users aren't really interested in flexibility.
Linux hope can't be in Hurd, because Hurd and Linux are mutually exclusive, Linux having being created because Hurd was taking too long. Go see Linus' announcements in Linux start of life. Rather, Hurd is a hope for the GNU Project and the free software community, especially that part of it that believes in copyleft and has lost hope in monolithic kernels. Meanwhile Linux was created out the GNU Project, while having a symbiotic relationship to it and depending on it; Linus believes in copyleft but not strictly; and he's more aligned to Open Source than to Free Software.
And Hurd has a chance at viability because of the microkernel plus multiple servers architecture inherent flexibility. So it could theoretically scale from small to big systems, and each configuration needn't include anything non-funcional or ill-suited.
Please do your research before babbling out.
Yeah, you nailed it down.
Now remember that the whole point of microkernels is to enable flexibility -- not only for development's sake but also to be able to adapt to different loads and usage characteristics.
So the HURD seems to be the answer. That or Linus (or someone else, or a group of kernel hackers) over a reasonable amount of time manages to get better at (1) understanding modifications to Linux and their consequences and (2) based on this understanding only release "stable" kernels once they're done.
Given the complexity of the task, I doubt it's doable. The free flavours of BSD never scaled as far as GNU/Linux; the proprietay Unices have basically choosen to scale up and up, forgetting the small systems situations and accepting bloatedness in order to cater for stability, resilience and other high-iron stuff. Even single-server microkernels like Windows NT and Apple Darwin haven't much to offer, being bloated, slow and not flexible at all.
We still have a free software and open systems advantage, because POSIX OSs can cover the whole gamut of computing systems simply by having different kernels with the same APIs; standard bodies and GNU libc are the real heros here, not Linux or BSD. Proprietary software usually will be even more fragmented, with all those slightly incompatible, underperforming, unstable versions of Microsoft Windows, Mac OS Classic and so on. But still it would be nice to have a free, copylefted common kernel. Unless the Linux situation improves dramatically soon, the only answer in the horizon is the Hurd -- and it still needs to be finished.