Slashdot Mirror

Your opinion is completely obsolete with today's selection of source code management systems. Distributed change control systems allow developers to commit frequently, and ensure that every commit actually does compile. I would be mildly disgusted to work with developers that commit changes that don't compile. See the list of points in this page for an explanation of what I think is the proper way to structure one's commits.

now.

here.

No standards? Are you serious? You've never heard of Linux Standard Base?

Giving a binary base for privative software vendors throwing their software wherever they like to, with half-assed start/stop scripts and without integration with the native package management tools of my distribution of choice?

Uh that's exactly what the LSB is trying to put a stop to. Currently, software installation sucks because it doesn't have integration with the native package manager. One of the reasons for forming a cohesive, extensible packaging API is so that any package can communicate with the package manager about it's existence. Normally, this isn't done unless you use packages for your specific version of your specific distro. This is beyond retarded, and will keep Linux fragmented and away from ordinary users who don't know what the fuck configure make make install means, not to mention have no clue how to solve problems in doing that when they arise.

Currently the Burgdorf API is the incarnation of the LSB Packaging API and it would be nice to receive more help on such a critical issue. The article was spot on in saying that this will also lead to increased stability in other APIs as it's silly to install ten different versions of one library just because it's API isn't stable. Updating the library, that's mostly OK, but the rigidity of library APIs will become more apparent/annoying once Linux programs are actually portable (yes, I know binaries exist, I'm talking about packages for automatic updates, package manager awareness, etc).

Everyone should support good standardized APIs for Linux to help make this happen. While some users will be OK with never installing any software outside their own little world except for what their distro maintainers bundle up for them, many users are interested in having direct access to so-called "third-party" programs, not only for their binaries but for automatic updates among other things. Who's not satisfied with being stuck with version X just because they're using distro X of a program they love? I don't think most users are, and they shouldn't have to wait for the distro gift if they don't know how to compile, or the annoyances of running a "disconnected" binary in which they have to create manual menu items for and manually update.

If Linux is to ever be actually available to the masses, for it to gain momentum through the easy sharing of software outside the box which is the immediate software repository, and make it actually easy for Linux software developers to write software for any and all Linux distros without their blessed consent, this project is critical. Any user that wants free, unfettered, easy access to software has every interest in installing the LSB packaging API or using a distro with it already installed.

P.S. Yeah, there are other answers like Klik, Autopackage, Zero Install, and others, but an API to allow any package to be installed so that it will provide immediate integration with the package manager is much more helpful. Until the packaging API is finished though these solutions will help.

I haven't looked at LSB 4, but in LSB 3 you'd make a standard .RPM package and it would supposedly install on any LSB-compliant Linux distribution.

See here for more: http://www.linuxfoundation.org/en/Developers/LSB_Tutorial#Porting_your_code_to_the_LSB

"LSB-conforming systems promise to be able to install an LSB-compliant RPM. However, you need not limit yourself to that format, with the caveat that the packaging technology you choose must work on an LSB-compliant system. For example, a shell script with a tarball is an acceptable format. Your own installer is acceptable, too, as long as the installer itself is LSB compliant."

Intel, how about supporting the LSB Package project so that once solidified will allow systems to install both RPM and DEB packages, as well as any others. Once software is easily installable cross-distro, distros will be reduced to mere collections of specific software, and you won't need to make silly decisions like that based on formats because any format will be possible.

Take a look at, and help with, the Burgdorf Packaging API, the current proposed solution in the making.

First I just have to say, awesome journal. Thank you so much for promoting cross-anything usability. In order for everyone to have access to all software, having that software use modular/extensible APIs/ABIs so that they can always function in the best way in any environment is very important. The Freedesktop project is very important in helping to bring more interoperability to the Linux system, so I wish them all luck in this struggle. It'll be amazing when a way can be found to make any program have the look and feel of the native desktop or whatever user-defined look that they want, and when configuration files and data can all be stored in similar locations, like just off the user's home directory, instead of being buried inside .kde or .gnome. Heck, I'll be happy when my KDE program menu icons start displaying correctly in Gnome.

While it's fine and great that Ubuntu has become a noticed distro, I'll be happier when "Linux" becomes more common. When you can download virtually any distro and it will simply be a specific selection of Linux software, but you can go out and easily download and install any Linux software or drivers you want. Then, it won't need to be "Ubuntu", it will just need to be "made for Linux". Some distros may not be concerned with cross-distro software portability because they have an interest in users coming to them for help, instead of to the actual upstream providers of the software, since some of these distros are based on wanting to create a need for support. However, just like not having desktop standards hurts everyone, not having easy cross-distro software installation does the same. Fortunately, there are projects like the Burgdorf Packaging API which are working on solving this issue, as well as more top-level solutions like Zero Install, and of course both of these projects could use more support from everyone. :)

But with Ubuntu you don't need that just about everything will work without any configuration.

You're right to some degree there, however the parent's point about penguins on the boxes is a huge problem. For Linux to be "easy", it has to have hardware which tells consumers that it's Linux-compatible. But the thing in the way of solving that is Tux's catch22: "Linux won't get support until it gets widely used, but it won't see wide use until it gets support." The problem is being solved, it's just slow. Even the supposed thing with ATI/AMD releasing their new graphics cards, the Radeon HD 48x0's, that would have Tux on the box never happened. Disappointing. However, since driver installation is still insane on Linux, it's not too surprising that manufacturers don't support it better. If they had a kernel module or API which OEMs could use for quick driver installation so you wouldn't have to compile or reinstall your driver for every kernel upgrade you went through, and could also provide an install package that could register itself with the most common package managers out there by using a universally accepted packaging API, then I think you'll start seeing that happening more. Examples of this effort include the Burgdorf Packaging API here. (Before someone says it, yeah I know giving it to the kernel devs to have them package it for you is another option, but Linux needs to be modular enough to allow either method to occur. Anything that helps adoption by helping easy installation is a good thing, and will increase Linux's adoption, and that's all I want to see happen. Users still will have the choice to use binary blobs or not, but they will have a lot more choices when Linux adoption becomes greater.)

I'm anxious to see progress with hardware support by having databases, or better yet more online stores selling Tux-compatible hardware so you never have to go to the store to begin with.

Because, again, Linux does not offer a standard ABI across distributions.

Linux Standard Base.

The author really likes skype. A lot. He has an nvidia card. He didn't do his research. He claims "Despite their concern, I would point out that NVIDIA has a fairly decent track record with bug control and, mysteriously, Linux developers have been able to make things work on their end despite this issue with the licensing behind the current closed source NVIDIA driver. " yet according to https://www.linuxfoundation.org/en/Linux_Graphics_Essay the proprietary nvidia and ati drivers and other binary drivers are regular features in the list of top kernel oops. When he talks about mp3s and encrypted DVDs and binary wireless drivers in the same sentence he is clearly confusing the issues of copyright license, software patents and the legality of breaking DRM and the like. I can easily play and encode mp3s and watch encrypted DVDs using only free software, that's free as in speech. His arguments are based on misunderstandings and poor research so they're not very interesting. He also completely misses the fact that the Linux kernel contains non-free and unattributable code which could be the subject of a much more interesting article.

Unfortunately, there isn't yet a choice to (insert Linux complaint here). :)

Time to get completely off-topic (well, almost, this IS the Linux section). Lets see, at the top of my list would be interoperability between Linux distros. I'd like a distro that was very compatible with cross-distro software package formats, so no matter what version I went to, I could always install the package, and so could others, even if they weren't using the same distro/version! Non-package-manager-hooking binaries don't count, I'm talking about packages which the manager recognizes, so I can easily remove the software later via the manager. Imagine having either a package format or a package container format standardized at some level or made compatible with managers, so you could actually share packages across the net, with OTHER distro users, and actually could install them, and Linux software could much more easily be shared! Mind-blowing, I know.

The most promising candidate for doing this so far seems to be Zero Install, so I hope it or a better solution is adopted.

P.S. Alien doesn't count either until it's capabilities are merged with existing package managers for easy one-click installation across any distro that uses that manager. I'm talking about a solution for those without CLI knowledge that want an easy one-click solution like Windows and Mac have. While I don't fall into this category, most others do, and that in turn effects me by effecting Linux adoption and thus developers who give a damn about penguins. :)

I recently set up a similar setup, but instead of load balancing across the two connections for everything, I needed to construct rules that decided if certain types of traffic (irc, http, etc.) went across which connections. If you choose to use any type of linux-based router, iproute2 will probably be what you'll be using, even if it is abstracted by some type of graphical tool. Consider the following links explaining iproute2:

The Linux Foundation's iproute2 page:
http://www.linuxfoundation.org/en/Net:Iproute2

These guys seem to be maintaining iproute2 now.

The "Linux Advanced Routing & Traffic Control HOWTO": http://lartc.org/howto/

This is probably the most thorough document on iproute2 and will cover absolutely everything you would need to know about it.

Specifically, look into load balancing:
http://lartc.org/howto/lartc.loadshare.html

This excellent page also explains how to make iproute2 and iptables interact with each other, so you can use iptables rules to mark packets for iproute2 to route over a certain interface:
http://lartc.org/howto/lartc.netfilter.html

Finally, this document provides some basic information about how to manipulate rules with iproute2, which is useful if you're trying to diagnose why it's not working correctly:
http://www.policyrouting.org/iproute2-toc.html

You know, the world's not exactly beating a path to Linux distros. It might not be the best idea to piss off a huge percentage of your intended audience, especially given that it's much more freedom-loving than most.

Some of these guys are anti-GPL as well. e.g.:

"The current license for Linux requires you give back any changes you make to the open source community, but there's no way anyone can require those assurances and there's no way we'd know," Marcus Rex, CTO at the Linux Foundation said.

Here are the members of the Linux Foundation. Oh, look, Novell is a platinum sponsor. Coincidence, I'm sure.

Although I'm sure everyone here doesn't need a link to remember the URL. . .

The link to the Linux Foundation in TFS is broken, it links to http://www.linuxfoundation.org/. A true slashdotter would know that it's http://www.linux-foundation.org/.

Update the link in the original front page post.

http://www.linuxfoundation.org/ is NOT http://www.linux-foundation.org/

The first is just a traffic collector page.

The Linux Foundation mentioned in the story is at
http://www.linux-foundation.org/

Thats where you will find the article/survey.