Attacking Lock-in In China

Efforts to free China from M$’s tentacles are growing more organized:“commentators said one of Dell’s goals was to please Chinese authorities. In the most recent revision of China’s procurement regulations, bidders who offer laptops preinstalled with Chinese Linux-based operating systems can get two extra points in their bid scores, according to China Government Procurement News.”

  • Government is attacking M$ for anti-trust and security
  • Government is promoting FLOSS, and
  • FLOSS developers are making moves to make a better product for the Chinese market: an app store for GNU/Linux with standardized API, and merging talents to create one big GNU/Linux OS for China

It remains to be seen how well all this will work but it’s an indication that the forces promoting FLOSS have realized that they have to unite to beat M$ at the OS game. That’s a pretty good recipe for success even if the road is long and uphill.

See Homegrown developers look to unseat Microsoft’s dominant OS.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , , . Bookmark the permalink.

8 Responses to Attacking Lock-in In China

  1. DrLoser says:

    And, for reasons we don’t need to bother our silly little heads about here:

    If you want software from it, you have to use their [the PRC’s] standards, whatever they turn out to be.

    Per definitionem, even though we have no bleeding clue what such standards will “turn out to be,” they will be infinitely preferable to closed-source “standards” invented by M$.

    Any comment on their relative merit compared to Open Source Standards, as espoused by you, Robert, before you went all giddy on this PRC Lurve thing?

  2. DrLoser says:

    They have a repository and if you want software from it, you have to use their standards, whatever they turn out to be.

    That’s very fair, Robert. There must be a huge demand out there for a single monolithic Linux distro designed and distributed on behalf of a bunch of raving unelected murderous kleptocratic maniacs like the Central Committee of the People’s Republic of China.

    I would certainly rely on their App Store, RPM or otherwise, to provide my every need.

    Linux is not love. Linux is a hammer which we use to crush the enemy.

    And let’s not forget the Great Leap Forward via backyard furnaces

    Gosh, was that a brilliant idea, or what?

  3. DrLoser says:

    (ram doesn’t need my “complete approval” or anything like it. I apologise, ram. What I meant to say is that every bit of that was something close to my heart and something that I think is as important as you do.)

  4. DrLoser says:

    I have hired Linux experts to rewrite/modify has been to to mate “historical”/legacy applications to recent Linux distributions, or vice versa — mate recent applications to legacy Linux platforms. Actually more of the later. In almost all cases the modifications have been trivial, mostly changing a few variable names. Unfortunately it requires hiring certain experts to find them and do it.

    I’m quoting ram’s comments with my complete approval here. I’ve high-lighted one particular section merely because it corresponds closely to what a Hero of Free Software (who will be quoted later) pointed out in a widely-read comment.

    I’ll briefly interject my own comment: why would anybody pull this bull? And, more importantly, why would anybody think it’s a good idea?

    If your software platform requires you to hire “experts” to track down something as trivial as variable renaming, then you are in for a world of pain. Which is what you get when you rely on uninformed idiots to “run, study and modify, redistribute and improve” — now that I come to think of it, that’s a blatantly stupid order of Freedoms — without regard to prior use or back-compat testing.

    Because what you get is a descent into API design by numbskulls with a personality disorder: Let’s just change a few variable names! (Oh, and reorder the parameter list. And break the contract with the users of a library without telling them. Hey, it’s FOSS — read the damn code!)

    OK, to cut a long rant short, here’s JWZ on the subject:

    I wrote this because you are all idiots.

    Specifically, if you were involved in the OpenGL specification between 2003 and today, you are an idiot.

    Allow me to explain.

    Let’s say you have a well-specified system that is in wide use (a language, a library API, whatever) and because of changes in some substrate (operating systems, hardware, whatever) you find that you need to add a new way of doing things to it.

    The way you do this is, you add new features to the specification and you clearly document the version in which those features become supported.

    If there are old features that you would like to discourage the use of, then you mark them as obsolete — but you do not remove them because thou shalt not break working code.

    If you don’t agree with that, then please, get out of the software industry right now. Find another line of work. Please.

    This is apparently not the most popular approach in Linux land.

  5. ram says:

    It would be convenient/useful/good if the APIs in major Linux appications did not change as often as they do, or at least be backward compatible. A fair fraction of the code I have hired Linux experts to rewrite/modify has been to to mate “historical”/legacy applications to recent Linux distributions, or vice versa — mate recent applications to legacy Linux platforms. Actually more of the later. In almost all cases the modifications have been trivial, mostly changing a few variable names. Unfortunately it requires hiring certain experts to find them and do it. Very fortunately, those experts can be found and are very very good — often fixing much more than they were hired to do.

  6. kurkosdr wrote, “you just can’t have “standardized APIs” in LinuxLand. They are against the spirit of constantly “improving” at all costs. “

    This isn’t about GNU/Linux. It’s about the app store. What they want is something any distro can tap into to get software. It’s more like a standard package. LSB apparently specifies RPM but some distros don’t do RPM or it’s an afterthought. Basically, the Chinese are trying to standardize on something within China. That’s all. This is certainly possible more or less the same way Google or Apple do it. They have a repository and if you want software from it, you have to use their standards, whatever they turn out to be.

  7. oiaohm says:

    kurkosdr
    Anyway, if they manage to standardize the API among Desktop Linux distros, it won’t be standard in the proper sense, aka “not changing all the time breaking back-compat.
    This is not true. Forwards compat is missing without providing runtime. Backward is true if the API/ABI is stabilized. There are a stack of tools that are used to confirm API/ABI stability.
    https://wiki.linuxfoundation.org/en/HeaderCheck LSB has provided a stack of stable ABI for a long time. In fact steam from valve demands that its runtime parts use these. Now if everyone making apps demanded that all libraries use conformance tools lot of problems would disappear.

    kurkosdr media container formats what are you smoking. The number of container formats for media is insane. Only three container formats wmv, avi ……Mpeg4 avc/H.264 gets worse that wmv has Microsoft customised version of H.264 same with other Mpeg4 avc/H.264 containers.

    Vorbis then Opus ok what. Early H.264 does not define a audio format at all. AAC was added latter as M4A early H.264 uses mp3 or DVD-Audio format for its audio. Sorry the same time frame again. FOSS has changed less.

    audio APIs, with OSS, then ALSA, then PulseAudio.
    Same time frame Microsoft has made more audio output library interfaces.
    http://en.wikipedia.org/wiki/Windows_legacy_audio_components
    Microsoft manage to invent 5 in the same time-frame and that is only counting the legacy ones you are not meant to use any more. Apple has done about 3 audio frameworks in the same time frame. 20+ years 3 major audio frameworks is quite light. Reality for Linux is more like 22 audio frameworks and only 3 to 5 are left depending on what you cound.

    OSS and ALSA application can still be used with Pulseaudio. OSS was not open source. Linux had an open source clone of OSS. You can still install the closed source OSS on Linux. There were on going issues with OSS implementing features than clone not working with them or audio card had X feature and OSS had no interface for this. ALSA was a result of opps OSS does not fit these cards they don’t support.

    Low level there are 3 audio frameworks on Linux OSS, ALSA, FFADO. OSS and FFADO devices can these days be accessed by ALSA applications.

    Pulseaudio is the end result of 8 different sound servers kicking the bucket. Jack-audio and pulseaudio are the two left sound servers. This is the 5. Pulseaudio accepts ALSA and OSS applications.

    Compression formats really stop looking through rose colored glasses. The said reality is closed source has made more. Like remember cab and msi from Microsoft ie lets go out and reinvent wheel. Surprisingly to most people rpm and deb are older format of compression . Deb is ar arcive and rpm is a cpio format. Please note both of cpio and ar appear closed source first.

    I have not had to decompress 1 .kgb or .7z file. I have stuck to zip and tar fairly much.

    Gzip is not a new compression it is in fact and implementation of http://en.wikipedia.org/wiki/DEFLATE in fact a closed source invention to get around patent problems. bzip2 on the other hand OSS and there are others. Majority of compression formats were invented and used by closed source tools and cloned into to open source. There have been more closed source compression formats go by by than open source compression formats that have ever existed.

    Because, why spend time and R&D to make a standard aimed at covering most of the expected use cases and avoiding most design mistakes, and have it last a reasonably long time, when you can push something poorly thoughout-out out of the door and then fix it by breaking compatibility?
    Really I would like Mpeg lla to answer that one. Mpeg4 avc/H.264 this is todays format but the history is worse. Those with rose colored glasses want to forget MPEG-4 Part 2 in other words the video compress format for Mpeg4 that was release that basically did not work. Yes they performed all the R&D tests on MPEG-4 Part 2 yet still managed to stuff it up completely. There is absolutely no compatibility at all between MPEG-4 part 2 and MPEG-4 Part 10 (Mpeg4 avc/H.264). Yes something is suspect when a standard contains 2 video formats. Reality Mpeg4 avc/H.264 should be Mpeg5 avc/H.264 but that would have been publicly admitting screw up. Mpeg1 and Mpeg2 only have one video encoding format. Mpeg4 is the exception with 2 video encoding formats in the base standard.

    Remember we are meant to be ramping up for H.265. Hardware makers today are a little smarter they are wanting to delay by 2 to 3 years to hopefully have H.265 debugged before they implement too much.

    kurkosdr FOSS is not the only one that has had to break compatibility to fix stuff. Sorry please compare on a fair playing field. You will find more often than not items like video and audio have been way worse in the closed.

  8. kurkosdr says:

    “an app store for GNU/Linux with standardized API”

    No, you just can’t have “standardized APIs” in LinuxLand. They are against the spirit of constantly “improving” at all costs.

    In fact, you can’t have standardized anything.

    Just look at video: With Theora, then Dirac, then Daaala. Instead of something that lasts a reasonably long time like Mpeg4 avc/H.264.

    Or audio. With Vorbis, then Opus (instead of just AAC aka M4A)

    Or container formats, with Ogg, then MCF, then MKV

    Or compression formats, with Gzip, 7z, then .kgb

    Or audio APIs, with OSS, then ALSA, then PulseAudio.

    … Because, why spend time and R&D to make a standard aimed at covering most of the expected use cases and avoiding most design mistakes, and have it last a reasonably long time, when you can push something poorly thoughout-out out of the door and then fix it by breaking compatibility? (*cough* Theora, OGG container, OSS *cough*)

    Priorities people!

    Anyway, if they manage to standardize the API among Desktop Linux distros, it won’t be standard in the proper sense, aka “not changing all the time breaking back-compat.

Leave a Reply