This could make funny clothes that change color on demand. Of course, it will also make life very difficult for people who cannot make up their mind: blue, no yell... argh....
is the fact the you cannot add the stuff in/Library/PDF Services (well you can, but it won't work). Did anybody else notice this. This is strange as usually you can choose to put stuff either in/Library,/Network/Library or ~/Library.
Anyhow, while this trick is cool (I use it to mail pdf files in one move) I hope we will soon have free tools that are equivalent to the classic Unix stuff for postscripts: putting multiple pages on one page, reordering pages, etc...
This is really good news, a long time ago pascal was the default language of Mac OS. My first Mac OS programs were all written in pascal. Ah, the time I spent reading the Inside Macintosh books.
I guess I'm not the only one, and there probably is a fair amount of old pascal code that is waiting to be ported to OS X.
If the carbon bindings are ported, recompiling should be reasonably easy.
One of the reasons to icons, imho, is that they are supposed to be universal. For example (your example) a mailbox is a bad symbol, as it is not universal due to cultural differences. However, letters, or rather, envelopes generally look the same, and thus make a better symbol. This is my view on how to use icons.
MMh, the problem, I think, is that icons should be at the same time powerful and clear symbols, and at the same time multi-cultural, this is in essence contradictory. A letter is a relatively good icon because it is very internationnal.
The problem is, you often need more complicated/subtle symbols for instance to reprsent verbs (thanks to all those toolbars). In this case, it might make sense to replace an icon, or even to replace an icon by text (or ideograms).
Consider for instance a graphical program with a button on a toolbar to center stuff. A western icon for such an action would probably be some icon with a centered object with some arrows comming from all directions. Maybe put a C on the objet to make it clearer. In a chinese or japanese, it would make sense to replace the whole thing with the Kanji representing center.
I'm not sure this example is a valid one, but the idea is simply in a different localisation, different symbols and layout can be more efficient.
Please don't take my replies as objections to your points. They are good points and apply to a great part of all software produced.
Thanks. God, I'm having a reasonable discussion on slashdot, I must have taken the wrong pill this morning.:-)
However, I think that the problem is quite easily fixed by a good design (which, in turn, Qt represents in many cases).
Actually, I have no doubt about the quality of Qt. The root question is more philosophical, i.e to what extent goes localisation - my belief is that it goes behond text, but you are probably right in 99% of the case, translating text is enough.
As for changing symbols. This can be avoided if the symbols are picked with care and cultural dependencies are avoided (i.e. do not draw a wooden log for the log-viewing-function).
Why not change the symbol depending on the localisation then? A letterbox might be a good icon for a mail program, but different countries have different letterboxes. Why not change icons in the localisation process? Finding truly multi-cultural symbols is hard.
Qt's flexible dialog layout algorithms ensure that the text is always visible.
While I agree that this is first step, the fact that all widgets are visible does not guarantee a nice layout or even a comprehensible one.
As I understand it (haven't tried myself) Qt can handle right-to-left texts, the rest is really in the text-showing widgets and translations.
As far as I know the problem is that you also need to reverse label and data fields if you are in some form-like interface. (Label first, field after wards). You might also need to swap the position of the default button of a dialog.
I simply think that doing the localisation outside of the context of the GUI is not the best way. It would be like translating a text sentence-after-sentence, without the ability of changing paragraph boundaries and such.
This approach is particularly annoying for complex dialog boxes where the text label should not be ambigous and the layout clear and precise.
Smart layout managers and nice object oriented design can do a lot, but except if you manage to program culturally aware layout managers, there is a limit at what they can do.
In the end, only a human eye can judge if an interface element makes sense or not. Sometimes, it makes sense, to add a tab/pane to a dialog instead of simply making it grow...
Personnally I like the way things are done in Cocoa.
Localised version of each file are stored in different directories. Strings are stored in separated files,
but also the layout of all GUI elements. Those
can be edited with the Interface Builder and changed as needed and the applications does not need to be recompiled, nor does the editor need access to the source code.
This makes it possible for a non-programmer to localise a program very easily and in a graphic fashion. In fact you can even test the behaviour of the layout manager (resizing etc...) in the graphical editor. This also means you can easily customise the interface of an existing application or even add you own localisations.
That localising an application does not simply mean changing the text strings and using an automated translator?
Making truly localisable applications is hard, a good toolkit helps as does unicode support, but many issues are simply a question of design and of understanding. While some points are raised in the linked article, others are not.
The first thing to understand is that you do not localise text, you localise resources. Window and dialog layout change depending of the language, so do icons (certain symbols have not the same meaning in different cultures). This is why layout should be described in resource files, not hard coded.
French texts are longuer than in English. If you fail to take this into consideration, your text will spill out of the text zone. I had a Redhat installer with this problem, french labels were always incomplete the end was always chopped off - and no, those text field did not become scrolling.
This was very annoying has help messages only contained text in the style of "this button does..."
Do not assume that certain data will always be printed in the same way, traditionnal (postal) address format changes from country to country.
Do not assume anything about the keyboard layout. Don't use shortcuts with keys that may no exist directly on some keyboards, like say control-].
Do not assume that text layout rules are the same in all the languages. French spacing conventions are different from English spacing conventions. No doubt that texts in other writing systems with ideograms or that read right to left have also different text layout rules.
Be very carefull when comparing strings. For instance in german, the umlaut can be changed into an 'e' that follows the letter. E.g Zürich can be written Zuerich. As people who don't understand umlauts simply strip them, Zürich can be written in three ways: Zürich, Zuerich and Zurich. Of course every language has its own specifics.
Do not assume that there is a correlation between interface language, sorting rules, date display rules, the keyboard layout and country specific settings like monetary units, the ways addresses are printed etc...
My machine is set up with an english interface, a swiss-french keyboard, and swiss french date display and sorting rules.
By the way, "My string in my native language" automatically translated into French gives you "Ma ficelle dans ma langue natale", which roughtly means "My small rope in my native language".
They article only compares the DNA system with DRAM for memory density. They don't talk about building DRAM using this technology.
The D in DRAM stands for dynmic, this is memory that needs to be update at regular intervals. I'm not sure this DNA technology will require refreshes (this is good).
In the article, they mention that their current plans are not for random access (those are the R and A in RAM.) I think this technology is closer to CCD memory where data can be fed and read in a sequential manner. For certain applications (like storing video data), this is sufficient, but for computer main memory, this is not well suited.
So basically, they will do DRAM, but without the DRA part. This is called memory.
Actually, they already do. If you look at recent apple mices, there is no button to speak of: the whole shell acts as a button. The change had a funny effect: my mother did not notice anything missing, she just clicked. While some geeks I know where quite startled and tried to find the button.
There is no mention of iSCSI on apple's site, and I never heard of apple supporting iSCSI.
You cannot run Linux drivers on Mac OS X, drivers is one area where Darwin is very different from Linux. You might have more luck with BSD drivers.
Running the drivers as command line makes little sense: drivers don't have much interfaces. You might need the command line to start or install drivers.
Assuming an iSCSI driver existed for Mac OS X / Darwin, then the system could see a remote device and handle it. Assuming the file-system on this device would be supported by Darwin then all applications, with or without GUI would 'see' this file-system.
The answer here is culture. Not so much traditional japanese vs american, but just a level of acceptance.
In the US comics are still seen as trash. the language of people who aren't bright and have nothing to do with their time better than waste life. This is not true however, the perception remains.
Very true, you see a similar phenomena in Europe, and in France in particular. Comics are relatively well accepted, and some of the classics are now a integral part of the culture. Adults read comics and no few people in France will think you are childish for reading Astérix (in fact it took my years to figure out all the jokes).
The funny thing, is that many of the reasons proposed for the success of manga are not present in France. Comics are not cheap (most of them are real book with some hard cover) and to big to read in the train (standard european comic format is roughly A4). Yet they are very popular.
I suppose this could mean that the G5 isn't fair away though.
Well I don't know if the G5 is not far away, but I'ma sure a G5 is not far away. A Gx is not really a product name or a processor model, it refers to a generation number.
The G1 was the 601, it was basically a scaled down POWER chip with still some POWER instructions.
The G2 were the 6xx series: 603, 604, 604e.
The G3 are the 7xx series: 740, 745, 750. This would also, I suppose, include the Flipper processor of Gamecubes.
The G4 are the 7xxx series: 7410, 7441, 7445, 7451, 7455.
The G5 looks like it will be the 9xx series: 970.
As to what makes a generation change, its not very clear. From G1 to G2, there was a change in the MMU and caching structure and the removal from POWER instructions. From G2 to G3, I think the wiring changed. The only difference between G3 and G4 is Altivec. The difference between G4 and G5 will probably be numerous: 64 bits (albeit the PPC 620 already was 64 bits) and different interconnect. (Somebody correct me if I'm wrong).
Unfortunately, those open source developers will almost certainly end up writing Cocoa IRC clients or something - ie software that can only be used on a proprietary platform.
You are probably right, people will prefer coding in cocoa, because it is a very nice programming API, you are wrong in assuming that those programs will only work on OS X. Cocoa code can be recompiled for GNUStep, which is fully open-source.
This whole story is here because most free software is portable, it's based entirely on open standards and free APIs.
I think you are mixing up two different things, the fact that software is open source, and the fact that the coding is done for a given API. There are many open source project that are targeted for the Win32 API.
Technically, cocoa is an implementation of an open standard: open-step.
You're easily impressed then. Darwin was mostly already open source, and has such poor hardware support it's nearly useless outside of the Mac.
Darwin is heavily modified version of the Mach system, it includes elements that do not exist in Mach, like the driver system, IOKit.
The fact that darwin does not run on your hardware is irrelevant. The fact that can't or don't want to use the code that is open sourced does not change its value.
They were legally obligated to give back the KHTML improvements - yet Safari itself is not open source, despite it being a merely average web browser in terms of features and standards support.
If safari is such a poor browser, why would like the source code? Or do you mean that because the browser is of low quality it should be open sourced?
Their contributions to FreeBSD have been in the order of a few trivial patches and some test suites according to Jordan Hubbard who seems to consider the positive marketing as their biggest contribution.
You are right, and the reason is simple, the BSD component of darwin is not recent at all. Basically Apple is still catching up, so they hardly have any improvement to give back and can only find a few lingering bugs. If when apple will be using current BSD code and won't give back its improving, then complaining will be justified.
What, pray tell, have they returned that they developed themselves outside of Darwin, which as I've already pointed out, is a nice gesture but ultimately useless. Chess.app?
While they were required to give back the changes for gcc because of the license, for all the others projects, they did not have to. The element that will probably be used first by Linux systems is rendez-vous. Whenever the other technologies will be adopted is an open question.
As for work on Chimera, I understand the feeling of the Chimera team. I agree that Safari is missing many features,
it is overall more finished that Chimera. For instance Chimera does not support services well and on my machine it tended to crash a lot.
While some feature will certainly make it to Safari, others will not. It would be nice if Apple would open-source the whole Safari, but I doubt this. Instead, what would be smart from Apple would be to have the browser support plugins, not only for displaying content, but also for controling network operations and maybe some aspect of the GUI. This way people could customise Safari.
As for tabs (the topic of probably 95% of the posts on this post), I don't think is such a good solution. While they are usefull, I feel they are not complete, mostly because the relationship between tabs is unclear: are they at the same level? On the same site?
Most of the time I used tabs, it was to explore some hierarchy and load in parallel multiple branches (say multiple links). What I really would like is something that displays this tree structure, with some options like "pre-load branch" and "attach link as branch". This structure could also use the relationships defined by the link tags. In fact this thing would simply expand the notion of hierarchical history (and in fact include future links). If done well, Safari could use the same panel interface for the hierachy as mail.
So, being able to make the decision making process finer grained is a seriously good idea. Of course people won't vote on everything, why should they, they'll vote on what interests them but then the same is true of MPs. I await the results of the experiment with interest.
Err, this is already done. In Switzerland if enough people petition for it, any question can be voted on. This is called direct-democracy and has been used in Switzerland for more than 150 years...
They use a "town hall" style of voting, where they meet in the town square, debate and vote normaly by a show of hands.
Groan. This system was only used in a few cantons and has been abandonned.
Yo may think that is arcane. But at least the woman got the right to vote in the late 1980s.
This was only in one of the smallest cantons and only for local affairs.
While I agree that the whole Appenzell affair is quite embarassing for Swiss democracy, your comment is a very broad and a gross generalisation. By this measure, the US is a dictatorship (well Bush was not elected democratically) with religious laws (sodomy laws).
You have to understand that voting in Switzerland is very different from voting in other countries (especially the US). Switzerland uses a system called direct democraty. Basically if enough people ask for it (by the way of petitions), any question is subject to voting. Add to this the fact that Switzerland is a three level confederation with votation at each level and your realise that there is a lot of voting in Switzerland.
So there are more than four votations a year in Switzerland, each votation concerns itself with laws or elections of multiple levels (votations on six objects are common). All this requires a very streamlined process and people are not very willing to go to polling stations because of voting. Because of the system, people have a very different relationship to voting.
While internet voting certainly could be tampered with, believe me, the other system was not very secure. For instance in my canton, vote by mail is done in the following way:
I get my voting papers by mail.
I write my birthday on the card.
I sign the card.
I fill in my voting bullletins.
Put everything back in the enveloppe.
Send it back by mail.
There are many ways to cheat, but the truth is nobody cares. Swiss people are all in all quite honnest and trying to cheat would be political suicide - something like the last US election would probably mean a lot of manifestations and a full redo.
Also the truth is, Swiss politics have little impact on the overall world...
I agree with you on the basic idea: if people could claim areas and/or resources outside of earth, this would encourage space exploration. The main problem is how to you accept a claim?
If we take the Alaska analogy, you have multiple things:
An authority that can grant property and police conflits (in this case the US governement).
A clear definition of how a claim is accepted (fencing the area and farming it).
A reasonably level playing field (while farming in Alaksa certainly involves some money, I think money is not the prime factor).
The problem is that for space affairs, the situation is not that clear.
There is no clear authority on space - the UNO has trouble enough solving problems on earth. What if a conflict occurs between different claimants? Do you really think that the US or China will accept a UNO ruling they don't like?
The basic idea of the Alaska is that you improve the area, make it civilised, livable. I agree that if an entity (state, corporation whatever) terraforms a planet, it ought to have claims on it. But defining this in a clear way will be tricky (and probably imply a new race of lawyers).
To take your proposal, does landing imply a human being? Very restrrictive, robots could be sufficient for mining. If not what if a country / corporation sent a thousands micro-robots scattered around the moon, they could claim most of it.
You made the comparison with patents, and the analogy holds, the problem is not so much with the concept, most people agree that a person should be able to claim an idea. The problem is to prevent some entity of claiming to many things.
The playing field is not level at all. There are basically five players: the US, the EU, China, Japan and Russia. Dividing extra-terrestrial ressources between those five entities would further the divide between rich and poor countries, this could lead to more anger from third world countries.
Yet I agree with you that this is probably the way to colonise space, simply I doubt this can be done in a peacefull way like Alaska. You might argue that space is big, the problem is, space is not very equal, it is full of unintersting places, with a few places with many resources, or a very strategic importance.
Check out the Objectweb project, and in particular Joram. Objectweb is a complete J2EE environnement that includes a MOM with a JMS interface. A XML-RPC interface is in the works.
The project is spear-headed by INRIA (a French research institute).
The whole system is open-source and they are doing quite advanced stuff (including group communications).
While Apple is certainly the main supplier of PPC based PCs, this emulation layer could make it possible to run Mac OS X on different PPC based machines that have some kind of NetBSD support:
Unsupported Apple machines.
IBM RS600 machines.
BeOS machines.
PowerPC-based evaluation boards.
Motorola MVME PowerPC SBCs.
PowerPC-based Amiga boards.
Whenever it makes sense to run Mac OS X on those beasts is another question altogether. Many of them probably don't have the horsepower for the GUI - some of them even don't have displays. The good news is that the lack of new PPC processor forces Apple to continue to optimise their system.
I suppose that if Mac OS X can run acceptably on one of those beasts, it will make sense to port darwin directly to it - in order for instance to use things like IO/Kit, but until then, it means people will be able to experiment and play.
Heck! imagine if such a compatibility layer existed for Linux, you could run Mac OS X of an AS/400...
While the basic functionality is similar, both approaches are quite different and quite complimentary. Dynamic DNS makes sense for servers that need to be reachable from the whole internet.
Dynamic DNS makes little sense if somebody plugs-in a laptop in a LAN. You don't want to update your DNS data to include a laptop that might stay connected for a few minutes! There are also administrative issues: DNS updates will certainly not be allowed for arbitrary machines or arbitrary DNS names.
Multicast DNS solves this problem nicely and even works when you don't have a server. So if a friend plugs a laptop in your home network you can address his machine using a logical name.
I was also suprised that Apple did not activate this for personal web sharing. It is nice that somebody corrected it. This said, in my case, the hack does not work correctly: it seems the advertised local address has a period after the.local domain, so the browser can't find the actual web server.
I really hope that rendez-vous technologies get ported to other Unixes soon. For instance, multicast DNS is really nice in LANs where IP addresses are assigned via DHCP. You can simply type something like ssh server.local and it works. When you use laptops, it is really a killer feature.
I don't know if this project fits your idea of network aware, but there is electric sheep. In this screen saver, computer join a collaborative task to calculate the next fractal to display. I think there are Linux, BSD and Mac OS X ports.
I don't know of a direct solution, but I would decompose this into two problems.
Tranform your documents into a reasonable format, XML, or very simple HTML: no page layout, only tables and lists.
Transform those files into text.
The first part is difficult as you have to filter the data and remove a lot of unneeded information, one possible way to do this would be to convert word documents into RTF, and then RTF into HTML (tools to do this, like RTFTOHTML).
The second part is quite easy. If your data is XML, you can convert it using simple scripts (tables might be an issue) if the data is simple HTML, you could could use Lynx to convert it into text with some layout.
In fact, I would keep both version of the data handy. Having a somehow strctured version of data never hurts, and text files do not take so much space.
Slashdot Mirror
This could make funny clothes that change color on demand. Of course, it will also make life very difficult for people who cannot make up their mind: blue, no yell... argh....
There is an article about this in the the register. Seems an english war reporter was threatened of having her communication uplink targeted.
Anyhow, while this trick is cool (I use it to mail pdf files in one move) I hope we will soon have free tools that are equivalent to the classic Unix stuff for postscripts: putting multiple pages on one page, reordering pages, etc...
I guess I'm not the only one, and there probably is a fair amount of old pascal code that is waiting to be ported to OS X. If the carbon bindings are ported, recompiling should be reasonably easy.
Consider for instance a graphical program with a button on a toolbar to center stuff. A western icon for such an action would probably be some icon with a centered object with some arrows comming from all directions. Maybe put a C on the objet to make it clearer. In a chinese or japanese, it would make sense to replace the whole thing with the Kanji representing center.
I'm not sure this example is a valid one, but the idea is simply in a different localisation, different symbols and layout can be more efficient.
Thanks. God, I'm having a reasonable discussion on slashdot, I must have taken the wrong pill this morning.I simply think that doing the localisation outside of the context of the GUI is not the best way. It would be like translating a text sentence-after-sentence, without the ability of changing paragraph boundaries and such.
This approach is particularly annoying for complex dialog boxes where the text label should not be ambigous and the layout clear and precise. Smart layout managers and nice object oriented design can do a lot, but except if you manage to program culturally aware layout managers, there is a limit at what they can do. In the end, only a human eye can judge if an interface element makes sense or not. Sometimes, it makes sense, to add a tab/pane to a dialog instead of simply making it grow...
Personnally I like the way things are done in Cocoa. Localised version of each file are stored in different directories. Strings are stored in separated files, but also the layout of all GUI elements. Those can be edited with the Interface Builder and changed as needed and the applications does not need to be recompiled, nor does the editor need access to the source code.
This makes it possible for a non-programmer to localise a program very easily and in a graphic fashion. In fact you can even test the behaviour of the layout manager (resizing etc...) in the graphical editor. This also means you can easily customise the interface of an existing application or even add you own localisations.
Making truly localisable applications is hard, a good toolkit helps as does unicode support, but many issues are simply a question of design and of understanding. While some points are raised in the linked article, others are not.
- The first thing to understand is that you do not localise text, you localise resources. Window and dialog layout change depending of the language, so do icons (certain symbols have not the same meaning in different cultures). This is why layout should be described in resource files, not hard coded.
- Do not assume that certain data will always be printed in the same way, traditionnal (postal) address format changes from country to country.
- Do not assume anything about the keyboard layout. Don't use shortcuts with keys that may no exist directly on some keyboards, like say control-].
- Do not assume that text layout rules are the same in all the languages. French spacing conventions are different from English spacing conventions. No doubt that texts in other writing systems with ideograms or that read right to left have also different text layout rules.
- Be very carefull when comparing strings. For instance in german, the umlaut can be changed into an 'e' that follows the letter. E.g Zürich can be written Zuerich. As people who don't understand umlauts simply strip them, Zürich can be written in three ways: Zürich, Zuerich and Zurich. Of course every language has its own specifics.
- Do not assume that there is a correlation between interface language, sorting rules, date display rules, the keyboard layout and country specific settings like monetary units, the ways addresses are printed etc...
By the way, "My string in my native language" automatically translated into French gives you "Ma ficelle dans ma langue natale", which roughtly means "My small rope in my native language".French texts are longuer than in English. If you fail to take this into consideration, your text will spill out of the text zone. I had a Redhat installer with this problem, french labels were always incomplete the end was always chopped off - and no, those text field did not become scrolling. This was very annoying has help messages only contained text in the style of "this button does..."
My machine is set up with an english interface, a swiss-french keyboard, and swiss french date display and sorting rules.
Actually, they already do.
If you look at recent apple mices, there is no button to speak of: the whole shell acts as a button.
The change had a funny effect: my mother did not notice anything missing, she just clicked. While some geeks I know where quite startled and tried to find the button.
The funny thing, is that many of the reasons proposed for the success of manga are not present in France. Comics are not cheap (most of them are real book with some hard cover) and to big to read in the train (standard european comic format is roughly A4). Yet they are very popular.
- The G1 was the 601, it was basically a scaled down POWER chip with still some POWER instructions.
- The G2 were the 6xx series: 603, 604, 604e.
- The G3 are the 7xx series: 740, 745, 750. This would also, I suppose, include the Flipper processor of Gamecubes.
- The G4 are the 7xxx series: 7410, 7441, 7445, 7451, 7455.
- The G5 looks like it will be the 9xx series: 970.
As to what makes a generation change, its not very clear. From G1 to G2, there was a change in the MMU and caching structure and the removal from POWER instructions. From G2 to G3, I think the wiring changed. The only difference between G3 and G4 is Altivec. The difference between G4 and G5 will probably be numerous: 64 bits (albeit the PPC 620 already was 64 bits) and different interconnect. (Somebody correct me if I'm wrong).Technically, cocoa is an implementation of an open standard: open-step.
Darwin is heavily modified version of the Mach system, it includes elements that do not exist in Mach, like the driver system, IOKit.The fact that darwin does not run on your hardware is irrelevant. The fact that can't or don't want to use the code that is open sourced does not change its value.
If safari is such a poor browser, why would like the source code? Or do you mean that because the browser is of low quality it should be open sourced? You are right, and the reason is simple, the BSD component of darwin is not recent at all. Basically Apple is still catching up, so they hardly have any improvement to give back and can only find a few lingering bugs. If when apple will be using current BSD code and won't give back its improving, then complaining will be justified. Ok, here we go again:- Gcc (altivec and objective-c related code)
- Quicktime streaming server.
- CDSA.
- Open Play.
- Netsprockets.
- Rendez-vous.
- Header doc.
While they were required to give back the changes for gcc because of the license, for all the others projects, they did not have to. The element that will probably be used first by Linux systems is rendez-vous. Whenever the other technologies will be adopted is an open question.While some feature will certainly make it to Safari, others will not. It would be nice if Apple would open-source the whole Safari, but I doubt this. Instead, what would be smart from Apple would be to have the browser support plugins, not only for displaying content, but also for controling network operations and maybe some aspect of the GUI. This way people could customise Safari.
As for tabs (the topic of probably 95% of the posts on this post), I don't think is such a good solution. While they are usefull, I feel they are not complete, mostly because the relationship between tabs is unclear: are they at the same level? On the same site?
Most of the time I used tabs, it was to explore some hierarchy and load in parallel multiple branches (say multiple links). What I really would like is something that displays this tree structure, with some options like "pre-load branch" and "attach link as branch". This structure could also use the relationships defined by the link tags. In fact this thing would simply expand the notion of hierarchical history (and in fact include future links). If done well, Safari could use the same panel interface for the hierachy as mail.
While I agree that the whole Appenzell affair is quite embarassing for Swiss democracy, your comment is a very broad and a gross generalisation. By this measure, the US is a dictatorship (well Bush was not elected democratically) with religious laws (sodomy laws).
So there are more than four votations a year in Switzerland, each votation concerns itself with laws or elections of multiple levels (votations on six objects are common). All this requires a very streamlined process and people are not very willing to go to polling stations because of voting. Because of the system, people have a very different relationship to voting.
While internet voting certainly could be tampered with, believe me, the other system was not very secure. For instance in my canton, vote by mail is done in the following way:
- I get my voting papers by mail.
- I write my birthday on the card.
- I sign the card.
- I fill in my voting bullletins.
- Put everything back in the enveloppe.
- Send it back by mail.
There are many ways to cheat, but the truth is nobody cares. Swiss people are all in all quite honnest and trying to cheat would be political suicide - something like the last US election would probably mean a lot of manifestations and a full redo.Also the truth is, Swiss politics have little impact on the overall world...
If we take the Alaska analogy, you have multiple things:
- An authority that can grant property and police conflits (in this case the US governement).
- A clear definition of how a claim is accepted (fencing the area and farming it).
- A reasonably level playing field (while farming in Alaksa certainly involves some money, I think money is not the prime factor).
The problem is that for space affairs, the situation is not that clear.- There is no clear authority on space - the UNO has trouble enough solving problems on earth. What if a conflict occurs between different claimants? Do you really think that the US or China will accept a UNO ruling they don't like?
- The basic idea of the Alaska is that you improve the area, make it civilised, livable. I agree that if an entity (state, corporation whatever) terraforms a planet, it ought to have claims on it. But defining this in a clear way will be tricky (and probably imply a new race of lawyers).
To take your proposal, does landing imply a human being? Very restrrictive, robots could be sufficient for mining. If not what if a country / corporation sent a thousands micro-robots scattered around the moon, they could claim most of it.
- The playing field is not level at all. There are basically five players: the US, the EU, China, Japan and Russia. Dividing extra-terrestrial ressources between those five entities would further the divide between rich and poor countries, this could lead to more anger from third world countries.
Yet I agree with you that this is probably the way to colonise space, simply I doubt this can be done in a peacefull way like Alaska. You might argue that space is big, the problem is, space is not very equal, it is full of unintersting places, with a few places with many resources, or a very strategic importance.You made the comparison with patents, and the analogy holds, the problem is not so much with the concept, most people agree that a person should be able to claim an idea. The problem is to prevent some entity of claiming to many things.
The project is spear-headed by INRIA (a French research institute). The whole system is open-source and they are doing quite advanced stuff (including group communications).
- Unsupported Apple machines.
- IBM RS600 machines.
- BeOS machines.
- PowerPC-based evaluation boards.
- Motorola MVME PowerPC SBCs.
- PowerPC-based Amiga boards.
Whenever it makes sense to run Mac OS X on those beasts is another question altogether. Many of them probably don't have the horsepower for the GUI - some of them even don't have displays. The good news is that the lack of new PPC processor forces Apple to continue to optimise their system.I suppose that if Mac OS X can run acceptably on one of those beasts, it will make sense to port darwin directly to it - in order for instance to use things like IO/Kit, but until then, it means people will be able to experiment and play. Heck! imagine if such a compatibility layer existed for Linux, you could run Mac OS X of an AS/400...
Dynamic DNS makes little sense if somebody plugs-in a laptop in a LAN. You don't want to update your DNS data to include a laptop that might stay connected for a few minutes! There are also administrative issues: DNS updates will certainly not be allowed for arbitrary machines or arbitrary DNS names.
Multicast DNS solves this problem nicely and even works when you don't have a server. So if a friend plugs a laptop in your home network you can address his machine using a logical name.
Different problems, different solutions...
I meant ported and adopted...
That's the problem with networking technologies, adoption is important.
I really hope that rendez-vous technologies get ported to other Unixes soon. For instance, multicast DNS is really nice in LANs where IP addresses are assigned via DHCP. You can simply type something like ssh server.local and it works. When you use laptops, it is really a killer feature.
I don't know if this project fits your idea of network aware, but there is electric sheep. In this screen saver, computer join a collaborative task to calculate the next fractal to display. I think there are Linux, BSD and Mac OS X ports.
- Tranform your documents into a reasonable format, XML, or very simple HTML: no page layout, only tables and lists.
- Transform those files into text.
The first part is difficult as you have to filter the data and remove a lot of unneeded information, one possible way to do this would be to convert word documents into RTF, and then RTF into HTML (tools to do this, like RTFTOHTML).The second part is quite easy. If your data is XML, you can convert it using simple scripts (tables might be an issue) if the data is simple HTML, you could could use Lynx to convert it into text with some layout.
In fact, I would keep both version of the data handy. Having a somehow strctured version of data never hurts, and text files do not take so much space.