When they did ASCII, it was a standard by the US, for the US, the mess it created in the high-ascii range (128-256) is still not resolved and I'm talking diacritical characters like those used in western european languages (French, German, Spanish etc...) nothing fancy or very exotic. Problem was, of course the europeans were not implied in the process.
Now they do a universal standard that should correct all problems and surprise, they don't actually bother to check with the implied persons. Even if they did, it would make sense to have provisions for a few unknown character sets (like ancient civilisations or the myriad of small groups of people living in lost parts of the world).
Anyway, if computer history has told us something, is that a 16bit range is never sufficient for practical uses. Well, just another sad example of one size does not fit all... But I suppose the slashdot response will be - why the hell don't they all speak/write english...
Apple has just finished an OS with a very advanced drawing mechanism (Quartz), and you think their best PR interst is to port an graphical app that doesn't even use one of their drawing mechanism (QuickDraw or Quarz). Face it, if the port is perfect the GIMP will simply be as good as on linux.
Apple's PR interest is to help Adobe come out with a version of Photoshop that uses this new graphical layer to have feature not available on windows. Rumor say's it's exaclty what's happening.
Face it, while Qt or GTK are nice toolkits, but for Apple the truth lies in their own technologies: display pdf, and the NextStep Framework (Cocoa).
Even in this case (MSIE ported to Cocoa) won't help you unless you port Cocoa to Linux. This migth be possible if you run GNUStep on a PPC linux machine but I would'nt count on it.
Of course if you have the source code of a cocoa port you could recompile it and run it on GnuStep on any plateform.
The file system is not case-sensitive, but case preserving.
It rembers the case - so if a file is called Readme.txt it will remain capitalised this way. But if you type rm readme.TXT the file will be deleted.
No, because MSIE runs on top of Carbon. So to have MSIE running on Linux, you would need to port the whole carbon library - which is basically the guts of the Mac OS. The OS X version of MSIE probably does no Unix library or system call (well maybe libc but well...).
Maybe it's me, but this article seemed very confused to me. The guy is basically mixing up Window Maker (a window manager for X11) and OpenStep. The distinction between the original NeXT System, Open Step, GNU Step and Mac OS X is not very clear either. He talks a little bit about Interface Builder, but not a word on the different technologies that power the thing.
This is really a shame, because a good explanation about the NeXT technologies would be the most welcome on slashdot. It would be intersting to compare features of the GNUStep/NeXT/OS X Framework against GNU frameworks like Gnome or KDE. This would make it possible to compare them, but also to see if they could be integrated.
Of course this would imply a real discussion, not the usual arguments like Gnome is going to rule the world and everything else is obsolete etc...
Ok while I think some idea are intersting, some points are contradictory for instance: why would you use karma points to disable adds while it is said higher in the text that it would be the first customisation.
On the whole such a system could work if and only if people trust the system. Here in switzerland you can put a sticker on your letter box that you don't want adds so you don't get adds that are not personally addressed to you. This information is stored in the telephone directory and is respected. I would gladly have such a cookie to signal I don't want to see adds.
If you want intelligent adds, which seems to be the point of this text, you need some way to profile people. This implies the following:
That users trust the profiler not to sell/abuse the profile (so it must be minimal). Given the record of most add companies this is a tricky part.
That the profile is respected, i.e when I say I don't want any add, I don't get any add. This will be a problem if there are n different companies with different policies, no standart, etc.
That users cannot get more adantages by short-circuiting the system. For instance if your profiling filtering is not better that what I can do with Junkbuster, there is no way I will use it.
That user can bypass the whole system without harm. This means that the system can work if there is no profile and accept this (i.e not require one), this would be usefull for intermittent connectiosn, but also for people wo don't like the system.
The add system should be a order of magnitude smarter and global. Even as my browser signals that my primary language of interst is Swiss-French, I still get adds for stuff in the US. This is the most depressing thing about spam and internet ads: the internet is suposedly global, but all the Spam relates to the US.
The system should support communities. Ie you somehow signal that your are part of some communities, and therefore the profile of your community is used. This would be usefull for groups and would also yield better privacy.
But is this true for the desktop? At this end the majority of users aren't technically accomplished and simply want to get things done. If there are half a dozen different types of system, each with their own way of doing things, then people are
either going to have to be trained for each one, or lose out on potential employment at offices using an OS they don't know.
This all adds to employer's costs, and cuts down on profitability. The effects will be subtle, but in the long-run it'll damage the economy, which has become increasingly reliant on companies utilising technology.
I think this argument is completely invalid for many reasons:
You could apply it to most consumer devices and tools. There are many different brands of cars, yet there are not different driver licenses. Why? because they share a set of common interface and concepts.
All the desktop system use the same metaphors to some extent (the only difference between folders between plateforms is their color). Pretending that having only one company insulates you from changes between brands ignores the fact that Microsoft is not very consistent with itself: compare DOS/ Windows 3.1 and Windows 95/98/etc... People had to be retrained anyway and will have to be again once Whistler/XP comes out.
Companies and users don't care so much about the OS than about application. Ask a basic user if his machine run NT or 95. A office worker is trained to use Office. The rest is absolutely irrelevant. This would be like standardizing car engines to simply driving. Nobody mentionned breaking up Office.
The argument that it will affect economy implies that breaking up the Microsoft monopoly might disturb the stability of the desktop computer and hence make companies loose money. There is no such stability. If there where, people would not need to buy new computer and be retrainned every two months.
Finally, there is the ideological question. Indeed a monopoly can bring stability. While I would like a lot of thing to be standardized in the computer world, I certainly would prefer it to be done by some international organisation, and certainly not by an american corporation. This is the most ironic part of it all. Having a corporation being defended by the arguments of socialists (better integration, stability).
Static linking is one solution, but it seems a little bit heavy handed. Disk space is one problem, but indeed not major one. Another problem is that the library cannot be shared. This means that two programs using the same library will have to load it in their memory space. This means more memory consumption and more loading time.
Another nice solution could be something like bundles under Mac OS X/Darwin. First the library system knows the version number of each library, and can load the one the application needs - this alone would solve the problem described here. Secondly the library can be installed inside the application's framework, so you have the benefit of static linking without having to build a monolithic program.
This means that you can solve such problems easily. Need a specific library? Move it into the bundle. Can use the normal library? Move it out of the bundle. Simple.
The DLL-hell problem comes, IMHO from the rather simplistic dynamic libray handling codesystem.
To have an idea about bundles, have a look at the article in on Ars Technica.
I think linking together to tightly the GUI and CLI is not a good idea. You would like to have both working in a independant fashion.
What would be a good idea is to have a better terminal model. Current terminal models basically asume you have a teletype. Many extensions have been written to handle additionnal stuff, but most concern what happens in the terminal the outside of the terminal does not exist. Programming this terminal is not exaclty pratical: terminal compatibility is still a major problem under Unix.
What I would think would make sense would be to have an unified advanced terminal interface.
This could include the same two context features found in web browser: the title, and the status message bar (eventually a progress bar). The idea would be that those new chanels should not contain capital information, but more informative data, like progress, context (working directory) etc...
Another feature I would like to have would be a notification mechanism, that is, the terminal would be able to post a notification (something more usefull than the bell) that the terminal would interpret in it's fashion. For instance by flashing the window, icon, maybe opening the window, or by playing a sound with some stereophonic indication of the position of the notifying object.
Some of these feature already exist in some terminal, but they are not standardised. Having a uniform and cross plateform interface would help those issues a lot.
The problem with your nice example is that you assume that you input is pure text. That's nice because that's all a keyboard can take.
Now look at any word processor. What are all those icons for. That's right, meta-information: how to display this text. So in your CLI example, if the guys wants to do layout, or styling, e.g use his computer as a cword-processing machine, and not a stupid teletype. He has to either know a meta language to express his layout (say Latex or Html) or have icons...
Well the problem is two sided. Yes, older people tend to think that young people cannot handle responsability. On the other hand young people tend to assume that oldies are stupid and don't understand the new, cool technologies and are basically neanderthal. It's very difficult to be on both sides of the fence: ergo young enought to be responsible, and not old enought to be considered stupid.
But honnestly,I think the problem is much older than computer science...
Second, the real meat of their OS is BSD/GNU, and that already runs fast on x86. And I really don't think the Apple crew is coding their GUI to the metal (i.e. in assembly, for specific hardware). So I don't think speed will be an issue. And they could always implement library compatibility with linux, as netBSD has...
This is not true. A lot of work done recently on OS X was about optimising the GUI not only for the G3/4 processors, but for for the Altivect unit found in G4 processors.
Aqua eats up a lot of performance, and is basically possible because of altivect (why do you think they do not use IBM's Power-PCs?).
So if they move to intel, they will have to rewrite all this stuff for MMX or whatever. This would require serious work.
This sounds as a great idea except your are assuming that OS X is simply a user interface. Granted Aqua is the thing everybody has been raving about, but the truth, is, a usual, under the hood.
Bundles are only one part of OS X, the other parts are the IO Kit (new driver architecture), Quartz (Display PDF) and the whole Next framework.
ostiguy: Apple isn't known for SMP, server market, scalability, etc, and on the desktop side, all the eye candy is being kept proprietary.
If they are not intersted in SMP, why the hell are they selling multiprocessor machines to the masses? The current high-end machines are dual processors. To my knowledge, they are the first major Personal Computer manufacturer do that.
They have every interst in having SMP working, and working well. The people doing graphics are one of the main market of Apple, those guys need processing power, this implies good SMP.
Re:Don't expect all of OS X to be open-source
on
JKH on OS X
·
· Score: 1
While I think Apple has no reason to give avain the cool parts of their new operating system, there are a few things that, if given away, could help both the Macintosh and the Unix community:
Netinfo - While NIS does the job, Netinfo seems to offer more capacities. An open source version of Netinfo would make integration of OS X machines in Unix Networks much easier.
Display PDF - Apple has certainly no reason to give away the Quartz Code. On the other hand, detailing the protocol for local and remote PDF rendering would be an intersting idea. X11 is way less powerfull than PDF and much less expressive.
Display PDF could be an nice option for a new Graphical system, especially if one could remote view Mac application from a Unix box.
It would, in any case, prompt the debate about an alternative to X11 which would be a good thing.
The framework system. Indeed, information in a Unix system is not structured. By giving away the codes than handles frameworks, apple could encourage people in the Unix crwod to use this model, better structured applications would certainly benefit Unix, and would make bundling and porting applications to OS X easier.
Fully Open source AU/X. Granted it's old, but it's Unix and runs on old (68K) machines. Perhaps it's worthless when compared to current Unix OSes, maybe not. Apple won't be making money with this one anyway...
Open source MAE, it's a full 68K macintosh emulator than runs on Unix machines. I still use it on my Sun station and it's a nice tool.
Apple certainly won't invest lot's of money to make old version of 68K software run smoothly on newer hardware, so having outside guys fiddle with it could help having better backward compatibility. For the Unix camp, having a free emulator means they can run old but nice productivity software. Word 5.1 in MAE is more user-friendly and run more smoothly than Star Office on my Sun station...
I won't pretend that these will change the world or endanger Microsoft or whatever, but it could offer some opportunities for both communities. And it does not endanger any revenue streams from Apple.
Gee this is typical of the way of thinking only with part of the numbers (usually the easy ones). The problem in you reasoning is that you leave out all the 'hidden' costs.
you assume that the disposing of the cheap things that is broken is free (which is the topic of this post, I think).
you completly neglect the changing factor.
True, buying a new car every two weeks might make sense in some economical logic, but you'll end up doing a lot of shopping and setting up. Think about computer, how many days do you loose when you have to change your computer and set up a new one.
You neglect the safety factor.
You assume that the failure of the cheap object will have no consequences. Usually things break down when you need them not to break down.
True, housing is much more expensive in europe, and even more so in switzerland. On the other hand, the roofs to not cave in or fly away when there is a little to much rain. I don't know the price of not having a roof and having all you things destroyed. Personnaly I would rate this as expensive.
In general, things that make sense for the economy are not always good for me or even the people in general. I'm sure many wars made sense for the economy... But then again I'm one of those commie europeans...:-)
I think discussing if english will be the language of the web is a moot point.
Because of historical reasons it will have strong english roots, but calling it english?
I don't think chinese or hindu will replace english for technical (ascii, keyboards etc...) and political (the US control the web) reasons.
But I'm sure that the language will be transformed by all those non-english people.
When most people barely speak a foreign language, they usually take their own language and translate the single words. This gives very mixed results.
The problem is different languages have different gramatical structures and different cultural contexts. Programs likes Babelsfish fare so poorly because they don't understand what they translate and so cannot map the cultural references etc...
In short, translation is not easy. There are not serious automated tools, and most people cannot make good translations, so they will make bad translations.
Economically, it makes more sense to get used to the bad english of people around the world, than teaching them correct english.
Will you call the resulting thing english? if it pleases you. You can also pretend that english is just some bad french and german slapped together.
IMHO the resulting language will be some wierd esperanto with the following characteristics:
Not spoken (people write bad english)
Uses simple ascii/latin character set.
Politicaly Correct (foreign speakers are not the only driving force, think about marketoids and lawyers).
Very simple grammar (the kind you can map into any language).
Context independant vocabulary - the kind of stuff programs like Babelfish can translate.
No clear or stable spelling - english already has two variants, and spell-checking is out even on./. It will be nice for me, I will be able not to worry about the diferent spellings for the same word between French and English.
In broader sense, maybe there will be no human internet language (in the sense that somebody speaks it), but merely some virtual language.
Imagine, in a few years all people will surf in their native language with on the fly translation.
Your logic is cyclic - because you consider the programming languages that exist and are dominant.
To say that it would not matter because it would need those elements, that may well come from the cultural context, doesn't make sense.
Many language don't have loop, conditions or function calls.
Even the design of processor might have been different. Another culture might have built object oriented processors, were the control flow is based on the data, not the processing units.
You could for instance consider a language based on German that would rely on concatenating class names to build hybrid classes (inheritance?), such a language maybe also have a reverse polish notation (the verb tends to be in the end in German).
Another thing you might consider would be a language were some behaviours might be implied by some declinaison. For instance a conditionnal form would express execution in a transaction. You could maybe express parallelism by using tenses, express priority using language levels (different terms/declinaisons). You might also use diminutive forms to build shorted data structure and so on.
My intuition would be that the history of programming languages would have been quite different if programming would have emerged from another cultural block than the english one.
Slashdot Mirror
It's not new, and alas not surprising.
When they did ASCII, it was a standard by the US, for the US, the mess it created in the high-ascii range (128-256) is still not resolved and I'm talking diacritical characters like those used in western european languages (French, German, Spanish etc...) nothing fancy or very exotic. Problem was, of course the europeans were not implied in the process.
Now they do a universal standard that should correct all problems and surprise, they don't actually bother to check with the implied persons. Even if they did, it would make sense to have provisions for a few unknown character sets (like ancient civilisations or the myriad of small groups of people living in lost parts of the world).
Anyway, if computer history has told us something, is that a 16bit range is never sufficient for practical uses. Well, just another sad example of one size does not fit all... But I suppose the slashdot response will be - why the hell don't they all speak/write english...
Apple has just finished an OS with a very advanced drawing mechanism (Quartz), and you think their best PR interst is to port an graphical app that doesn't even use one of their drawing mechanism (QuickDraw or Quarz). Face it, if the port is perfect the GIMP will simply be as good as on linux.
Apple's PR interest is to help Adobe come out with a version of Photoshop that uses this new graphical layer to have feature not available on windows. Rumor say's it's exaclty what's happening.
Face it, while Qt or GTK are nice toolkits, but for Apple the truth lies in their own technologies: display pdf, and the NextStep Framework (Cocoa).
OS X has native NFS support. It simply well hiden. For more info, have a look at this site.
Even in this case (MSIE ported to Cocoa) won't help you unless you port Cocoa to Linux. This migth be possible if you run GNUStep on a PPC linux machine but I would'nt count on it.
Of course if you have the source code of a cocoa port you could recompile it and run it on GnuStep on any plateform.
The file system is not case-sensitive, but case preserving.
It rembers the case - so if a file is called Readme.txt it will remain capitalised this way. But if you type rm readme.TXT the file will be deleted.
No, because MSIE runs on top of Carbon. So to have MSIE running on Linux, you would need to port the whole carbon library - which is basically the guts of the Mac OS. The OS X version of MSIE probably does no Unix library or system call (well maybe libc but well...).
Maybe it's me, but this article seemed very confused to me. The guy is basically mixing up Window Maker (a window manager for X11) and OpenStep. The distinction between the original NeXT System, Open Step, GNU Step and Mac OS X is not very clear either. He talks a little bit about Interface Builder, but not a word on the different technologies that power the thing.
This is really a shame, because a good explanation about the NeXT technologies would be the most welcome on slashdot. It would be intersting to compare features of the GNUStep/NeXT/OS X Framework against GNU frameworks like Gnome or KDE. This would make it possible to compare them, but also to see if they could be integrated.
Of course this would imply a real discussion, not the usual arguments like Gnome is going to rule the world and everything else is obsolete etc...
Ok while I think some idea are intersting, some points are contradictory for instance: why would you use karma points to disable adds while it is said higher in the text that it would be the first customisation.
On the whole such a system could work if and only if people trust the system. Here in switzerland you can put a sticker on your letter box that you don't want adds so you don't get adds that are not personally addressed to you. This information is stored in the telephone directory and is respected. I would gladly have such a cookie to signal I don't want to see adds.
If you want intelligent adds, which seems to be the point of this text, you need some way to profile people. This implies the following:
I think this argument is completely invalid for many reasons:
All the desktop system use the same metaphors to some extent (the only difference between folders between plateforms is their color). Pretending that having only one company insulates you from changes between brands ignores the fact that Microsoft is not very consistent with itself: compare DOS/ Windows 3.1 and Windows 95/98/etc... People had to be retrained anyway and will have to be again once Whistler/XP comes out.
This is the most ironic part of it all. Having a corporation being defended by the arguments of socialists (better integration, stability).
Static linking is one solution, but it seems a little bit heavy handed. Disk space is one problem, but indeed not major one. Another problem is that the library cannot be shared. This means that two programs using the same library will have to load it in their memory space. This means more memory consumption and more loading time.
Another nice solution could be something like bundles under Mac OS X/Darwin. First the library system knows the version number of each library, and can load the one the application needs - this alone would solve the problem described here. Secondly the library can be installed inside the application's framework, so you have the benefit of static linking without having to build a monolithic program.
This means that you can solve such problems easily. Need a specific library? Move it into the bundle. Can use the normal library? Move it out of the bundle. Simple. The DLL-hell problem comes, IMHO from the rather simplistic dynamic libray handling codesystem.
To have an idea about bundles, have a look at the article in on Ars Technica.
I think linking together to tightly the GUI and CLI is not a good idea. You would like to have both working in a independant fashion.
What would be a good idea is to have a better terminal model. Current terminal models basically asume you have a teletype. Many extensions have been written to handle additionnal stuff, but most concern what happens in the terminal the outside of the terminal does not exist. Programming this terminal is not exaclty pratical: terminal compatibility is still a major problem under Unix.
What I would think would make sense would be to have an unified advanced terminal interface. This could include the same two context features found in web browser: the title, and the status message bar (eventually a progress bar). The idea would be that those new chanels should not contain capital information, but more informative data, like progress, context (working directory) etc...
Another feature I would like to have would be a notification mechanism, that is, the terminal would be able to post a notification (something more usefull than the bell) that the terminal would interpret in it's fashion. For instance by flashing the window, icon, maybe opening the window, or by playing a sound with some stereophonic indication of the position of the notifying object.
Some of these feature already exist in some terminal, but they are not standardised. Having a uniform and cross plateform interface would help those issues a lot.
The problem with your nice example is that you assume that you input is pure text. That's nice because that's all a keyboard can take.
Now look at any word processor. What are all those icons for. That's right, meta-information: how to display this text. So in your CLI example, if the guys wants to do layout, or styling, e.g use his computer as a cword-processing machine, and not a stupid teletype. He has to either know a meta language to express his layout (say Latex or Html) or have icons...
Well the problem is two sided. Yes, older people tend to think that young people cannot handle responsability. On the other hand young people tend to assume that oldies are stupid and don't understand the new, cool technologies and are basically neanderthal. It's very difficult to be on both sides of the fence: ergo young enought to be responsible, and not old enought to be considered stupid.
But honnestly,I think the problem is much older than computer science...
I agree, maybe it would be time to have a heading about User Interfaces in general.
This is not true. A lot of work done recently on OS X was about optimising the GUI not only for the G3/4 processors, but for for the Altivect unit found in G4 processors.
Aqua eats up a lot of performance, and is basically possible because of altivect (why do you think they do not use IBM's Power-PCs?). So if they move to intel, they will have to rewrite all this stuff for MMX or whatever. This would require serious work.
This sounds as a great idea except your are assuming that OS X is simply a user interface. Granted Aqua is the thing everybody has been raving about, but the truth, is, a usual, under the hood.
Bundles are only one part of OS X, the other parts are the IO Kit (new driver architecture), Quartz (Display PDF) and the whole Next framework.
If they are not intersted in SMP, why the hell are they selling multiprocessor machines to the masses? The current high-end machines are dual processors. To my knowledge, they are the first major Personal Computer manufacturer do that. They have every interst in having SMP working, and working well. The people doing graphics are one of the main market of Apple, those guys need processing power, this implies good SMP.
While I think Apple has no reason to give avain the cool parts of their new operating system, there are a few things that, if given away, could help both the Macintosh and the Unix community:
It would, in any case, prompt the debate about an alternative to X11 which would be a good thing.
I won't pretend that these will change the world or endanger Microsoft or whatever, but it could offer some opportunities for both communities. And it does not endanger any revenue streams from Apple.
Gee this is typical of the way of thinking only with part of the numbers (usually the easy ones). The problem in you reasoning is that you leave out all the 'hidden' costs.
True, housing is much more expensive in europe, and even more so in switzerland. On the other hand, the roofs to not cave in or fly away when there is a little to much rain. I don't know the price of not having a roof and having all you things destroyed. Personnaly I would rate this as expensive.
In general, things that make sense for the economy are not always good for me or even the people in general. I'm sure many wars made sense for the economy... But then again I'm one of those commie europeans... :-)
I think discussing if english will be the language of the web is a moot point. Because of historical reasons it will have strong english roots, but calling it english?
I don't think chinese or hindu will replace english for technical (ascii, keyboards etc...) and political (the US control the web) reasons. But I'm sure that the language will be transformed by all those non-english people.
When most people barely speak a foreign language, they usually take their own language and translate the single words. This gives very mixed results. The problem is different languages have different gramatical structures and different cultural contexts. Programs likes Babelsfish fare so poorly because they don't understand what they translate and so cannot map the cultural references etc...
In short, translation is not easy. There are not serious automated tools, and most people cannot make good translations, so they will make bad translations. Economically, it makes more sense to get used to the bad english of people around the world, than teaching them correct english.
Will you call the resulting thing english? if it pleases you. You can also pretend that english is just some bad french and german slapped together. IMHO the resulting language will be some wierd esperanto with the following characteristics:
- Not spoken (people write bad english)
- Uses simple ascii/latin character set.
- Politicaly Correct (foreign speakers are not the only driving force, think about marketoids and lawyers).
- Very simple grammar (the kind you can map into any language).
- Context independant vocabulary - the kind of stuff programs like Babelfish can translate.
- No clear or stable spelling - english already has two variants, and spell-checking is out even on
./.
In broader sense, maybe there will be no human internet language (in the sense that somebody speaks it), but merely some virtual language. Imagine, in a few years all people will surf in their native language with on the fly translation.It will be nice for me, I will be able not to worry about the diferent spellings for the same word between French and English.
Your logic is cyclic - because you consider the programming languages that exist and are dominant.
To say that it would not matter because it would need those elements, that may well come from the cultural context, doesn't make sense. Many language don't have loop, conditions or function calls.
Even the design of processor might have been different. Another culture might have built object oriented processors, were the control flow is based on the data, not the processing units.
You could for instance consider a language based on German that would rely on concatenating class names to build hybrid classes (inheritance?), such a language maybe also have a reverse polish notation (the verb tends to be in the end in German).
Another thing you might consider would be a language were some behaviours might be implied by some declinaison. For instance a conditionnal form would express execution in a transaction. You could maybe express parallelism by using tenses, express priority using language levels (different terms/declinaisons). You might also use diminutive forms to build shorted data structure and so on.
My intuition would be that the history of programming languages would have been quite different if programming would have emerged from another cultural block than the english one.