Slashdot Mirror
The Linux I18N And Standard Base Merge
Leo Comitale writes "According to this press release the Linux Standard Base and the Linux Internationalization (I18N) project have merged and are calling themselves the Free Standards Group. I think it is really important for Linux to have a basic, low level standard for file system layout and support for international languages. These areas are critical to keeping Linux from splintering into a bunch of incompatible variants, and it seems these efforts are not getting as much support as they probably should be."
So much software is USA-centic even english speaking Biits and Aussis feel left out. Imagine if your name is müller and your software won't even let you spell your name correctly.
Old COBOL programmers never die. They just code in C.
Except one: RedHat (and thus Mandrake, etc). Kind of careless of me to drop such flamebait rich material, but I cannot escape from the expression that RedHat does seem to have its own mind, sometimes for the better and sometimes for the worst.
My biggest fear is that one or two of the big distributions will not team up. It's pretty much a all or nothing issue. If even one decides not to adhere to the standards things are pretty messed up for they would not really be standards anymore.
Then again, I've also learned that as long as you stick to *one* package tool you won't run in to trouble. I prefer source, someone else [rpm|deb|tgz|foo]. As long as we keep things a little organized ourselves, we'll be all fine.
I would not hire any administrator who could not overcome the differences that exist. And those same differences should not be a big problem for the non-power user either since they are most likely to stick to one distribution anyway. Even if they wouldn't.. if you can make the transition from another OS to Linux, surely you can also learn to make the transition (either in thought or actual OS transfer) between distributions.
That, or I have a way too bright view of the future and computers (and their users).
I mean, sure, they've got a bucket full of endorsements from some of the big players, but since when does adding members to a group speed up the decision making process? I mean, each of the major Linuxes have a financial interest in their own success, even if it's at the expense of the others, right?
That said, I supported the idea of the LSB, and think this is a good thing, but is this any closer to something like a W3C decision making body than it's two predecessors?
I also wonder how the FSG's members propose to deal with applications for non-Intel processors. If software is written for an x86 Linux, and is "FSG compliant", does that mean it should be recompilable for Linux PPC, etc.? My other (probably dumb) question is that if I write something that works on a distribution that is supposed to be "FSG compliant", but don't have the various distributions to test it on, how am I supposed to be able to get my software tested and certified?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Second, I don't see it particularly important to internationalize this layout. What kind of ugly precedent would this set? If I wrote a program for a German-language compiler, would my code have to read:
wenn (foo != foobar) {
schreib ("foo und foobar sein anders.\n");
}
As it is, UN*X is pretty far removed from English, anyway. Don't mess with /etc...
--
--
fat lenny's gonna lick your brain today.
I'm all for a standard that allows applications to be written that can work seamlessly across Linux distributions. BUT. I hope this does not degenerate into uniformity. Let me explain.
When Oracle first decided to release version 8 for Linux, I was very interested and downloaded it. However, I found out that apparently it was only targeted for RedHat, and I, a Debian user, couldn't get it to work properly. Libraries were missing, and the installer insisted upon a particular path to JDK, which was extremely annoying. There isn't even an option for me to specify an alternate search path or anything. It was hard-coded, and so were certain libraries that had Debian equivalents but were in a different location.
What I'm trying to get at is, although a unified standard for where stuff should go in Linux is good, I fear that this may encourage developers to become lazy and simply assume a certain configuration and give no option for reconfiguration. For example, assuming that JDK must be installed in /usr/local/jdk/ or some such. I mean, I don't have a problem if they used /usr/local/jdk/ as a default, but if they don't allow you to re-configure where you want your stuff to be, that's very bad.
Now, I realize that the initial download of Oracle I had was probably a hurried hack, so it's probably not their fault (that was probably the first thing they ever released for Linux IIRC -- not surprisingly they went for the commercially better known RedHat). But it underlines a problem with a lot of application developers: hard-coding platform-specific assumptions and leaving no room for reconfiguration.
I know that it's easier (and arguably, results in more efficient products) to code for a specific platform, perhaps for the future Linux Standard. However, not allowing any room for reconfiguration is very annoying, and limits the scope of the application. An app that can be configured (with various amounts of effort) to run on, say, any UNIX system, would be more successful than one that just had to run on Linux because it was hard-coded with some directory paths or some obscure libraries that only existed on Linux.
Programs should be portable, more or less (ie. it should come with reasonable defaults that can run as-is on the specific system it was designed for, but it should not require massive recompilation or source-level hacking to get it to work on a slightly differently-configured system). A standard is meant to serve as a reasonable default, and not as an excuse for lazy, non-portable programming habits.
---
mikre he sophia he tou Mikrosophou.
Why do we need this? We've already got Red Hat to define the standard. Take a look at all the software that only runs on Red Hat Linux. Geez, why don't you just give up running incompatible distributions, and use the one true distro? I don't understand why people can't just follow the group. No, they have to do their own thing. These people are ruining Linux for the rest of us!
--
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
There's alot of debate for and against standards in the Linux community and in the open source community in general.
/usr or /local, just pick one! Let's leave the room for innovation in things that really matter and make sure that simple things like deploying applications are as easy as possible.
Arguments against: Stifles innovation.
Arguments for: Prevents fragmentation.
My take is that certain administrative OS things should be standardized just to make our lives easier. I mean who really cares whether files go in
Hotnutz.com - Funny
One of the problems with the existing standards proejcts is they not only define what the layout is, but they also define the package manager and the init-scripts format..those being rpm and sys V, respectivly. I personlly perfer the non-sysV version of the init files that Slackware uses...but they are someone appaled by posssibly being forcged to use rpm.
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
However, there are a few pieces of underlying support necessary:
As for native speakers of American English (of which I am one), even if you are monolingual, there is a decent chance that you would like to have customers in other countries with names constructed out of funny characters. Having the software you run handle their names correctly doesn't hurt. Frankly, I'm not at a disadvantage if all the menus, error messages and help files are in English. But I need to be able to enter data that contains foreign characters. Internationalization benefits more people than you realize.
The net will not be what we demand, but what we make it. Build it well.
Do these two groups really need to merge to make decent internationalization a "fundamental" part of Linux? What is gained by a merger, rather than having the Standard Base folks read the I18N folks papers and incorporate them? I'm not implying that either group is unimportant, but merely that I don't see a significant change offered by an actual merger.
An announcement that there was a draft standard for implementing multi-language or unicode support in Linux distributions would be important. This isn't.
The Free Translation Project has been handling the internationalization and localization of free software (primarily, but not exclusively GNU software) for quite some time. If you are interested in help internationalizing a program, or in participating in a translation team, it is a good place to start.
The net will not be what we demand, but what we make it. Build it well.
RMS has traditionally been opposed to the LSB because they are not called the "GNU/Linux Standard Base". Now they are the "Free Standards Group", I wonder if he can now bring himself to endorse them?
:)
Admittedly, their press release was full of "Linux" with no "GNU", but that's a press release and they're traditionally full of s**t anyway
Stuart.
I don't understand it sometimes. We (the open source movement) want to have our software (Linux) take on the superpowers of the Software world (Microsquat) yet we have a hard time agreeing on wheather or not their shoule be standards. It's scary, and I hope this is a move in the right direction.
Of course, that's just my opinion, I could be wrong.
Does anyone know if this includes support for BiDirectional languages? (Arabic and Hebrew).
For languages based on the Latin character set (or even a non Latin set like Cyrillic, Kanji, ...etc.) it is a piece of cake to "localize" an application. Just make sure everything is in a message file for the appropriate language, for the labels, menus, errors, ...etc. and you are home free.
However for Arabic (and Hebrew) the challenge is totally different. Display goes from Right to Left, and characters have different shapes depending on their position in the word and what other characters follow/preceed it.
I am using Windows and Internet Explorer because there is no Linux product that supports all this in full.
There are projects to arabize Mozilla, and the new New KDE/Konqueror 2 has Arabic support. This is all very encouraging, but nothing in production yet. Also, we need Arabic spreadsheets, word processing, calendar and scheduling PIMs, ....etc.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
No, no one is flaming (or should be flaming) people writing software in their own language. I don't know where you got that from. If you're talking about closed-source apps, I might agree that people might complain about English being the only choice. But with open source - no. The standard "do it yourself" often apply, interpreted as "translate it yourself". No need to rewrite the entire app, if the app was made cleverly. gettext will parse many c programs just fine.
No one expects you to translate your software into 11 zillion different languages. What you might do, however, is to make it easier for translators. This may be such things as not hard-coding US-ASCII everywhere. This may sound simple, but I've seen many programs not accept filenames with non-US-ASCII characters, or where such characters simply break the app.
It might also be to write the strings in your app so that they are easy understandable even out of their context. This helps translators a lot. Avoid TLAs when you can and write easy understandable sentences.
Also try to avoid assuming that all others whould like the same localization as you. Don't hard-code these settings in your application for example:
- AM/PM clock
- Legal paper format
- Weeks begin on Sunday
- Date formats and date strings
- Inches
I could go on and on, but you get the idea. These are things that can get people "burst their arteries" if hard-coded.As for american programmers writing in english: Don't assume that most programmers writing applications in English are american. If you look at the contributor list of many free software projects (like the GNOME and KDE ones) you'll see that a lot of them are not from the US, maybe even the majority. English just happens to be the default language that applications are written in, and then translated into as many other languages as possible.
Disclaimer: I am a Translation Project translator, translating GNU software.
GNU/Linux. The Freshmaker.
Character sets and fonts that support your alphabet must be supported.
Good point. For example, what if the Unicode character space doesn't include a particular alphabet, the alphabet your language uses? All the i18n and l10n in the world won't save you in that case.
Will I retire or break 10K?
Up until this point, the LSB and Li18nux were operating as unincorporated organizations, which is bad for a number of reasons: legal liability, the inability to accept and distribute funding for development and other expenses, no entity to hold copyrights for the group, anti-trust issues (you need to be careful when you have competitors meeting in the same room), and more. We needed to incorporate (as a non-profit, of course).
As far as the Li18nux and the LSB are concerned, they will more or less continue as before, although we'll be able to put more resources on each project so things will speed up. We'll be working closer together and referring to each other's specification, but the LSB and Li18nux specifications will probably be separate standards for some time.
Why incorporate together? It makes sense and it's less overhead. We didn't need separate legal entities for these open-source standardization efforts.
Some LSB specifics:
Will the LSB be multi-architecture? Yes, although x86 is the main target, we are trying to draft the specification to apply for multiple architectures. Recompile the sample implementation and test suite and everything should work fine for other architectures. (The reality is that most third party software is released for Linux on x86.)
Another thing: the whole "LSB stifles development" argument is very misleading. You can ship development libraries along with stable LSB versions if you want both environments. (It will be up to the distribution and system administrators.) Kernel developers like Alan Cox, Ted Ts'o, and H. Peter Anvin have been participating in the LSB for a long time - I don't think that would happen if we were going to stifle forward progress.
Will having more members slow us down? Quite the opposite, actually. The main thing slowing us down is the amount of work to be done, not slow decision-making or the lack of consensus.
Finally, recall that the word "base" is part of the Linux Standard Base name. Distributions will still have the same amount of room to add value, innovate, and distinguish themselves. We like the fact that there are different Linux distributions, each with something unique to offer. We just disagree about requiring commercial and non-commercial providers of software to port and test their software for five or ten different Linux distributions.
Have you been to the Unicode site lately? But there is one problem: there are more distinct characters in this world's writing systems than there are 16-bit integers; some scripts will never be included into the codespace.
Will I retire or break 10K?
This is so common its almost funny. And very american... "hey theyre complaining about us using our own language!"
If you just took a look at the problem even you could understand. My language has three additional letters, å ä ö. Most asian languages use a whole different character set. How funny would you think it was if you couldn't make your application accept your name, or type a filename in your own language?
It's not about the language you code in, it's about the lower-level language possibilities of the system.
I support the internationalization stuff, but hwoo boy, what's with all this: "those stupid americans write software in American english! What, do they think theirs is the world's only language? When will they wake up and start writing software in Spanish and Portugese?!?"
Really, please, show me one example of where someone said anything similar to that... I've surely never seen anything remotely like it.
It just makes you look stupid.
Tomorrow will be cancelled due to lack of interest
This same discussion has been going on for as long as I can remember (which is not that long, but a good few years anyway).
'We need a standard to stop Linux fragmenting and becoming incompatible', etc etc. But has it happened so far? Hardly. Can you name an application which runs on one distribution but not another (for reasons other than corporate stubbornness)?
De facto standards seem to have served Linux well so far, why bother getting all formal and churning this sort of thing through endless committees?
-- Ed Avis ed@membled.com
>The newly formed Free Standards Group > was organized to accelerate
>the use and acceptance of open source
> technologies through the
>application, development and promotion of >interoperability standards
> for open source development.
Ok, so where are the calls to make sure this "Linux Standard" will be including Linux compatibility options?
>any LSB-compliant application will run >successfully on any LSB-compliant Linux >distributions.
Again, what about vendors that use a Sys V or BSD kernel and wish to support Linux via a Linux compatibility layer?
>increasing compatibility among Linux and other
>open source distributions and in helping to >support software vendors and developers to port >and write software for open source
>such as Linux.
Nice, but vague.
If it is OpenSource, it doesn't NEED the LSB like shrink-wrapped binaries does it? Look at all the code as FreeBSD ports and the same code as Linux distros rpm/deb/whatever
>LSB would also help
>SCO's Server Software Division by increasing >Linux compatibility with SCO operating platforms.
So why is SCO a 2nd class citizen in this? Why is the concept of Linux Compatibility layers buried at the end? Such should be at the top of the press release, because the LSB is the 1st *REAL* chance of a unified-shrink-wrapped-unix binaries in the history of Unix.
If it was said on slashdot, it MUST be true!
"All I truly want is a nearly universal dependancy/packaging/installation/uninstallation system. rpm comes close"
Last I knew, rpm is dependant on a database (not binary based like Windows) to figure out those things. That means it is no where near universal and depends on everything else being an rpm. You can do cross packaging with alien, but you soon learn that for it to really work rpm needs to
1) Better catalogue its own dependancies.
2) Play nicer in configuration file placement.
Some of the rest of your vitrol is kind of cute, somewhat insightful but overall meaningless since I would rather judge an ideas technical merits rather than motivations (patting themselves on the back, etc...) ascribed by some misinformed outsider.
Also a post mearly questioning "Why are they doing what they are doing?" in the middle of a sea of posts explaining exactly that makes one sound impetuous (jumping before looking.)
^~~^~^^~~^~^~^~^^~^^~^~^~~^
bash-2.03$ whereis netscape /usr/lib/netscape /usr/X11R6/bin/netscape /usr/bin/X11/netscape
/usr/bin. So, it is incorrect to say that "Linux" does this. Debian has defined things like this very specifically in their Debian Policy Manual for package maintainers, and certain others would do well to follow.
netscape:
bash-2.03$
This is on my Debian system. I also do not like the fact that RedHat really likes to throw everything into
Debian also does not install telnetd, etc. (and enable them!) by default. If you haven't tried Debian GNU/Linux before, I would highly recommend it...I used to use RH, but I've been completely sold on Debian and now run it on all of my machines. Even if it were not for the directory issue, apt-get would have won me over.
WMBC freeform/independent online radio.
Well, I consider users and independent developers a stakeholder as well. Of course individually, it is difficult to raise their voice but when united in a lobbying organization (e.g. the FSF) they can have a meaningfull vote.
I think large companies are entitled to some vote for the simple reason they invest a lot of money into linux and opensource.
Jilles
ESR wants the tengwar in Unicode so he can use them to write the Lojban language.
Will I retire or break 10K?