Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Designing Good Linux Applications

michael posted more than 12 years ago | from the not-an-oxymoron dept.

Linux 209

An Anonymous Coward writes: "A guy from IBM's Linux Impact Team in Brazil has written a guest column on Linux and Main describing how applications should integrate with Linux. It's Red Hat-centric, but there is a lot of material about the FHS and LSB that most users probably don't know."

cancel ×

209 comments

Sorry! There are no comments related to the filter you selected.

Sad News - Goatse.cx guy DEAD (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3219972)

I just heard the sad news on BBC radio. Web entreprenuer/pioneer goatse.cx guy was found dead in his home this morning. Even if you never admired his work [slashdot.org] , you can appreciate what he did for the 'last frontier' of the internet.

Reports are that he died from complications resulting from \"Developers: Designing Good Linux Applications\". Truly a internet icon. He will be missed :(

Re:Sad News - Goatse.cx guy DEAD (-1)

Serial Troller (556155) | more than 12 years ago | (#3220076)

You forgot stripslashes() in your script, eh? GOOD JOB man!!

It would be cool if Compaq had such a team... (4, Funny)

WIAKywbfatw (307557) | more than 12 years ago | (#3219989)

...'cos the common abbreviation for a Compaq Linux Impact Team would be interesting.

(Apologies in advance to all /. readers who have no Y chromosone and/or who don't appreciate South Park-style humour.)

Re:It would be cool if Compaq had such a team... (2)

digitalunity (19107) | more than 12 years ago | (#3220041)

How about: Compaq Linux Impact Team Of Really Important Software

Seems appropriate with their Linux Clustering tech...

Re:It would be cool if Compaq had such a team... (2)

NanoGator (522640) | more than 12 years ago | (#3220103)

"(Apologies in advance to all /. readers who have no Y chromosone and/or who don't appreciate South Park-style humour.)"

More accurately, it's Red Dwarf style humor... I certainly had a laugh at it. =)

Reminds me of when my company announced they had hired a Director Of Product Engineering. Being a Dilbert fan, I would have leapt at the opportunity to make his business cards....

Re:It would be cool if Compaq had such a team... (2)

mgblst (80109) | more than 12 years ago | (#3220287)

From Red Dwarf:

"I think we're all beginning to lose site of the real issue here, which is, what are we going to call ourselves? I've narrowed it down to two suggestions. The League Against Salivating Monsters, or, my own personal preference, the Committee for the Liberation and Integration of Terrifying Organisms and their Rehabilitation
Into Society. Uhm, one drawback with that, the abbreviation is CLITORIS."

Rimmer in POLYMORPH

Re:It would be cool if Compaq had such a team... (2)

BlueUnderwear (73957) | more than 12 years ago | (#3220145)

Seems such an aptly named organization does indeed exist: see this comment [slashdot.org]

First of all, (4, Insightful)

ultrapenguin (2643) | more than 12 years ago | (#3219994)

before going to design NEW linux applications,
PLEASE take your time and DEBUG the current ones.
The collection of half-abandoned software that has tons of bugs that nobody uses (perhaps of those bugs) is absolutely huge.

Re:First of all, (1, Troll)

mark_lybarger (199098) | more than 12 years ago | (#3219999)

like maybe the HTML used for the article. it renders horribly on ie 5.5.

Re:First of all, (0, Troll)

BlueUnderwear (73957) | more than 12 years ago | (#3220032)

like maybe the HTML used for the article. it renders horribly on ie 5.5.

Then use a real browser instead...

Re:First of all, (2)

mark_lybarger (199098) | more than 12 years ago | (#3220046)

i tried on mozilla and i'm still having to scroll right on to read the article. BAD HTML

Re:First of all, (2)

BlueUnderwear (73957) | more than 12 years ago | (#3220054)

Funny, I tried lynx, and had no such problem...

Re:First of all, (-1)

Serial Troller (556155) | more than 12 years ago | (#3220070)

But my terminal doesn't WRAP LINES!!!

Re:First of all, (1)

mark_lybarger (199098) | more than 12 years ago | (#3220088)

guess we all should have a good old copy of lynx laying around in case of emergencies such as this.

Re:First of all, (0)

Anonymous Coward | more than 12 years ago | (#3220091)

It renders fine in Opera 6, however you are right, the HTML is awful. The layout is simply two columns, and the left column is given 100% of the screen width, pushing the remaining right column out (at least, for a browser that obeys this). Due to the mass of content in this specific page there is no need for any width definition and setting the right-hand column to nowrap would achieve better rendering (to retain the same coding style). The tables make full use of the TBODY tag and yet they use it to mark-up table headers too (which is incorrect). They use TT rather than CODE for code fragments (code is preferred).

The body of content is in one large table, so - depending on the browser - it may take have to load the entire page before displaying anything. If I were to do the page I would right align a table and put within the right-hand-side content, and let the main body of content flow around it.

Re:First of all, (1)

Tyndareos (206375) | more than 12 years ago | (#3220010)

Maybe, if you have time, you can read the article.

Re:First of all, (2)

mark_lybarger (199098) | more than 12 years ago | (#3220021)

it really is hard to read when you have to scroll right on every line. these lines don't wrap.

Re:First of all, (2)

BlueUnderwear (73957) | more than 12 years ago | (#3220069)

Use a browser that doesn't support page widening ;-)

Re:First of all, (5, Interesting)

ianezz (31449) | more than 12 years ago | (#3220216)

As much as I share your desire, I think there is something deeper going on:

IMHO, to attract OSS developers, a piece of software has to be:

  • Useful to the developer, or at least it should offer the perspective to be useful in the near future. Otherwise there is very little motivation do mantain/debug software (sorry, I don't buy at all the idea that a OSS developer puts his time and brain in doing something exclusively for the good of humanity or users).
  • Easy to understand, extend and debug: if it isn't easy to grasp the whole picture, or at least grasp the picture of a whole subsystem, OSS developers will leave the project in frustration after a while, starting their own. The fact that large (successful) projects like Gnome, KDE, Mozilla and OpenOffice are divided in several smaller components, and the Linux kernel itself, although monolithic, is divided in several subsystems, should tell something on the subject.
  • Well documented (for developers): because it's hard to grasp the big picture only by looking at the sources when the codebase is large: you end just seeing a lot of trees, but you lose yourself in the forest. Sources tell a developer how something is implemented and how it is supposed to be extended, but usually they tell very little on why things have been implemented that way. Intelligent comments in the code are good, but when a concept spans on several source files, a README on the subject or a tutorial are definitively needed.

By any way, I don't pretend that these are anything more than a few rules of thumb, but in the end I'm sure that, for OSS software having the characteristics above, developers willing to do maintenance will show up by themselves without needing to preach them.

Re:First of all, (4, Insightful)

CanadaDave (544515) | more than 12 years ago | (#3220226)

Programs that were abandonned were abandonned for a reason. Either there were too many bugs, the design was poor, or there is just no demand for it. There's no sense in working on an application just because it doesn't work. It's the natural selection process of Linux programs. The strongest survive. If a program is buggy and people really want to see it work and happen, it will get some attention eventually. Linux is a perfect supply demand scenario in most cases. When developers want Linux to do something they just make an application. The advantage of course over Windows is that other people usually come in to help out, and the code is all over the internet.

There are more and more stable applications out there now, however. Take Mozilla for example. The long awaited 1.0.0 should be out in a month or so. An XMMS the MP3 player which is as good as they get (thanks of course to huge demand for a good MP3 player), OpenOffice.org which is slowly creeping towards their 1.0 release and beyond, KDE3/Koffice(and KOffice doesn't have many developers, partly due to low demand, but I think that will change soon). Things have really improved in the last year I think, and 2002 will be a big year as well.

Re:First of all, (0)

markyd (517099) | more than 12 years ago | (#3220263)

Nah, first they need to build a decent operating system.

Integrated applications (0, Insightful)

October_30th (531777) | more than 12 years ago | (#3219997)

Integration is bad as shown by the bloated Microsoft applications.

It's far better to do things in the *nix way: small, interacting but separated utilities that communicate via pipes.

Re:Integrated applications (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220039)

...separated utilities that communicate via pipes

... like Monica and Bill?

Re:Integrated applications (-1)

October_30th (531777) | more than 12 years ago | (#3220048)

Well, I wouldn't mind Monica connecting with my fat pipe.

I wanna get piped with Fiorina! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220199)

Well, I wouldn't mind Fiorina connecting with my even fatter pipe!!

Could it be? (-1)

October_30th (531777) | more than 12 years ago | (#3220390)

Could it be that you're expecting me to mention Hillary now? Been reading my posts before?

Well, OK.

I'd fancy a session with Senator Rodham-Clinton in which her strap-on dildo and riding crop would connect with my tight ass.

Re:Integrated applications (2, Insightful)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220173)

Your post could be interesting if you had explained to us why integration is bad. IMO, the yields of object separation over integration packs have belong to the fact you'd compile separate parts of code such as libraries, device drivers and kernel, instead of being tied by a Windows-like central management and interpretation for kernel and virtual machines. Then, "separation" benefits *nix. On the other side, "integration" benefits Windows.

Re:Integrated applications (-1)

October_30th (531777) | more than 12 years ago | (#3220351)

if you had explained to us why integration is bad

You're absolutely right.

I didn't explain why integration is bad, because I wanted to see if /. moderators will moderate a -1 posting troll like me up for posting just a few lines of Microsoft bashing and Linux/*nix praising. Looks like they will.

If only... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220002)

Oracle software worked like this...*sighs*

Graphical installers? (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#3220015)

Especially if it is a commercial product, your application must provide a graphical installer. Believe me, they are impressive in a demonstration, and CIOs love them.

What kind of crap is that? Any geek will tell you that if some software can't be batch-installed remotely, it isn't worth shit.

Packaging and Testing (3, Insightful)

Bronster (13157) | more than 12 years ago | (#3220017)

While he doesn't mention Debian [debian.org] at all, it's clear that the article is strong on packaging. I actually prefer Debian's approach, having a list of sources from which you obtain software, and providing search tools for that list.

The other important thing is that programs often don't work very nicely with each other, or need certain versions to work. This is where having a central system for controlling dependencies is rather important. I don't actually think Debian goes far enough at the moment (not really handling Recommends with apt), but it's getting there.

The other important part of packaging is handling upgrades automatically. Packages have security problems, they have new features added. If you have to work out (a couple of months later) which --gnu-long-opts-enable --with-features --without-bugs you had to put on the ./configure command line to get a build that did what you wanted, you're likely to put off upgrading.

# echo "http://debian.brong.net/personal personal main" >> /etc/apt/sources.lists
# apt-get update
# apt-get install bron-config

Whee ;)

(note - that URL doesn't exist yet, but it's my plan for the future).

(note:2 - no ssh private keys in that ;)

Re:Packaging and Testing (1)

mshiltonj (220311) | more than 12 years ago | (#3220230)

The other important thing is that programs often don't work very nicely with each other, or need certain versions to work. This is where having a central system for controlling dependencies is rather important.

You mean, something like a Registry? ;)

RPM is the standard, and APT works on it (3, Informative)

Nailer (69468) | more than 12 years ago | (#3220232)

Anyone running Red Hat 7.2 or many other RPM based distributions can easily install apt (or a similar tool, like urpmi, tho I prefer apt) to do the same thing.

The advantage there is that RPM is a standard - currently the older RPM (version 3) is included in the Linux Standards Base, but once Maximum RPM is updated for RPM 4, its extremely likely that RPM 4 will become the standard.

If you're using Red Hat I highly recommend installing it.

rpm -Uvh http://enigma.freshrpms.net/pub/apt/apt-0.3.19cnc5 5-fr7.i386.rpm

apt-get check
apt-get update
apt-get install

Re:Packaging and Testing (1)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220250)


While he doesn't mention Debian at all, it's clear that the article is strong on packaging. I actually prefer Debian's approach, having a list of sources from which you obtain software, and providing search tools for that list.

The guy who made that doc signs there he works for IBM.
His intention clearly was to do straight points about "how to do this", and from a basic standpoint. Thus he mentioned everything a lot RHS-like, probably targeting the newbies.
Linux experts won't have such a problem to assimilate his guide and to make adaptations for their needs.

/usr/local obsolete? (5, Insightful)

Osty (16825) | more than 12 years ago | (#3220034)

From the article:

/usr/local, /opt

These are obsolete folders. When UNIX didn't have a package system (like RPM), sysadmins needed to separate an optional (or local) application from the main OS. These were the directories used for that.


I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong. Perhaps /usr/local is obsolete with respect to package managers, and that makes some sense (because the package manager should handle proper management of placed files, though in practice that's not always the case), but as long as open source is around, there will always be software that is compiled rather than installed through a package manager. There will also always be applications that are not distributed in your package format of choice (as long as there is more than one package management system, this will always hold true). In these cases, it's still a good idea to keep around /usr/local and /opt. Personally, I'll have /usr/local on my systems for a long time to come, because I prefer to use the Encap [encap.org] management system.

Re:/usr/local obsolete? (-1)

October_30th (531777) | more than 12 years ago | (#3220042)

it's still a good idea to keep around /usr/local and /opt.

No it's not because then you have to keep on modifying .bashrc (or whatever) so that $PATH points to the new binary directory and $LD_LIBRARY_PATH to the libraries.

If something's userfriendly, that's it.

I gave that shit up a long time ago. All my stuff goes to /usr/bin and /usr/lib now.

Re:/usr/local obsolete? (-1)

Serial Troller (556155) | more than 12 years ago | (#3220057)

/usr/local/bin
/usr/local/lib

Dumbass.

Re:/usr/local obsolete? (-1)

October_30th (531777) | more than 12 years ago | (#3220364)

So how's that any different from /usr/lib and /usr/bin then?

Once again you would have a huge number of libs and bins in one directory and you would still have to add /usr/local/lib and /usr/local/bin to your environment.

What's the point?

Oh, I get it. It's the "Unix Way" to put your own stuff in local. What a load of semi-religious bollocks...

Re:/usr/local obsolete? (0)

Anonymous Coward | more than 12 years ago | (#3220082)

/usr/local is for my shit.
You can restore the distro's shit with a reinstall,
but you'd better take extra special care of your
own shit. Unless you only use the distro's shit
via the distros package manager. Then don't worry
about it, distro will help you know where to go today
and be very user friendly, so you don't need to know
what's what and where.

Re:/usr/local obsolete? (5, Insightful)

Tet (2721) | more than 12 years ago | (#3220097)

I understand that this is directly from the FHS, and not some evil concoction from the mind of the author, but dammit, I think it's wrong.

Actually, no. It is from the diseased mind of the author of the article. He first cites the FHS, and explains how good it is to have a standard like that, and then proceeds to ignore everything it says. /usr/local is explicitly reserved for local use and therefore no package should *ever* install itself there (my /usr/local, for example was NFS mounted, and RPMs that tried to install there would fail because root didn't have write access to it). So far, so good, and we're in agreement with the article. But then he goes on to say that /opt should never be used. What? According to the FHS, /opt is exactly where IBM should be installing stuff. Quite how he's decided that the two directories are obsolete is beyond me. Both have well defined and useful purposes, both in common usage, and in the latest FHS spec (see http://www.pathname.com/fhs/ [pathname.com] ). I'm afriad IBM have just lots a lot of respect from me for this...

Re:/usr/local obsolete? (1)

Osty (16825) | more than 12 years ago | (#3220112)

Actually, no. It is from the diseased mind of the author of the article.

My bad, then. I'm not 100% familiar with the FHS myself, so I made the (poor) assumption that when the author said that's what the FHS defines, he was speaking authoritively. Apparently not. If slashcode would allow editing of comments, I'd fix this assumption.

Re:/usr/local obsolete? (3, Interesting)

Krapangor (533950) | more than 12 years ago | (#3220192)

The latest version of the IBM JRE (v1.3) installs in /opt. So they don't seem to take his ideas too serious.

Re:/usr/local obsolete? (3, Informative)

ggeens (53767) | more than 12 years ago | (#3220104)

I understand that this is directly from the FHS.

Not true. This is what the FHS [linuxdoc.org] says about /usr/local:

The place for locally installed software and other files. Distributions may not install anything in here. It is reserved solely for the use of the local administrator. This way he can be absolutely certain that no updates or upgrades to his distribution will overwrite any extra software he has installed locally.

/opt is not mentioned as far as I can see. I remember reading that it was deprecated.

/usr/local is not obsolete, and won't be. The only rule is that a package manager (dpkg, rpm,...) should never touch that directory (beyond creating it on a new install).

Re:/usr/local obsolete? (2, Informative)

cy (22200) | more than 12 years ago | (#3220306)

/opt is not mentioned as far as I can see. I remember reading that it was deprecated.

/opt is not deprecated. In fact it is required that LSB compliant applications are installed under /opt You can download the latest version of the FHS here [pathname.com] and the LSB specification here [linuxbase.org] .

/opt is in FHS (5, Informative)

Skapare (16644) | more than 12 years ago | (#3220307)

/opt is in FHS 2.2 [pathname.com] at secton 3.12. It begins:

3.12.1 Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package.

Doesn't look very depricated to me. I think the problem is your FHS link isn't really the FHS; it is the SAG (Systems Administrator Guide) [linuxdoc.org] , which in section 4.1 [linuxdoc.org] clearly says it is loosely based on the FHS.

As for /usr/local, I do agree it should be off-limits to the distribution (besides setting it up if not already present). And packages in the package format of the distribution (e.g. RPM for Redhat, Mandrake, SuSE, etc ... DEB for Debian and any like it ... TGZ for Slackware ... and so on) really should stay out of /usr/local. What /usr/local should be is whatever is local policy (FHS doesn't say it this way). Packages that the administrator really wants to be separate from the package management system, stuff compiled from source, stuff locally developed, all is eligible to be in /usr/local. My guess is the author of the article has no experience doing system administration combined with a decision making role where he might have to choose to do something slightly different than what everone else does.

Re:/opt is in FHS (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220371)

Do not send me money via PayPal anymore.

So how can I send you money? Because I would really like to send you few grands for that comment and I've no idea how... Please, tell us. I'm sure there are lots of people who'd send you money if they only knew how.

Re:/usr/local obsolete? (2)

Nailer (69468) | more than 12 years ago | (#3220245)

but as long as open source is around, there will always be software that is compiled rather than installed through a package manager.

Source sode should be installed through a package manager. If you're a systems administerator and don't know how to package applications, you need to learn because you need it to do your job.

If you have the brains to compile from source, you have the brains to make a source package. I'm tired of inheriting somebodies backyard apache installed, with a bunch of forced packages and non packaged apps. I can't repeat that install on other systems (especially annoying when testing) the install optiosn used aren't documented, and as the author didn't include an `uninstall' target in his Makefile, I can't uninstall it properly (unless I use something like stow, but in that case I may as well package the goddamned app).

Because there's missed dependencies, I find out when something neeeds somethign else when it breaks, rather than before I install it. How it breaks is different with each app. Same with finding out if that app is installed, and how various files on the system got there. In other words, non packaged systems are an absolute mess and I have little time for them.

Learn to package. It's simple, and you and the machines you will manage will be happier for it.

dependency hell (3, Interesting)

Skapare (16644) | more than 12 years ago | (#3220341)

After using many versions of Slackware, I finally tried Redhat at version 5.1. Actually I had tried it at a way earlier version and it never successfully installed. But 5.1 worked OK. The reason I tried it was I bought a Sun Sparc 5 and wanted to try Linux on it. Redhat seemed to be OK, so I later tried it on a couple other i386 systems, and that was working OK ... for a while. As it turns out, I needed to make upgrades before RPMs became available (see next paragraph). I also needed to make some changes in how things were built. The RPM system started getting out of sync with what was actually installed. The system ran just fine, but soon it got to a point where some packages I was installing with RPM would not install because the RPM database thought things were not installed which actually were (but weren't installed from RPM, so I can understand why it didn't know this). So I ended up having to do forced installs. And that ended up making it more out of sync. By the time I had gotten to Redhat version 6.0, I was getting fed up with it. I switched back to Slackware (and Splack for Sun Sparc eventually came out and I use that, too) and am happy again, with well running systems. And I am now exploring LFS [linuxfromscratch.org] .

You say the system administrator should know how to package applications? Why the system administrator? I'd have thought you'd have expected the programmer to do that. If I get some package which is just a TGZ source file tree (because the developer was writing good portable code, but not using Linux to develop on), why should I, in the system administrator role, have to be one to make a package out of it? I'll agree it doesn't take more brains than needed to properly install the majority of source code, but I won't agree that it is easy (in terms of time spent) to do. At least I have the brains to actually check the requirements of what a given package I'm compiling needs, and make sure it is there by the time it is actually needed. The dependency may not be needed until it is run, so I have the flexibility of installing in whatever order I like. Also, some "dependencies" are option, and don't need to exist unless a feature is to be used that needs it. For example, if I'm not using LDAP for web site user logins, why would I need to make sure LDAP is installed if some module that would otherwise use it is smart enough to work right when I'm not using LDAP.

Re:/usr/local obsolete? (1)

Flossymike (461164) | more than 12 years ago | (#3220252)

I've only been using Linux for a few month now, and it is an area I'm unsure about, how does package management relate to software you compiled yourself?

I'm learning debian, but this is an area that it would nice to see answered

Hi there. Fuck you!! (-1)

Serial Troller (556155) | more than 12 years ago | (#3220040)

  • 2002. Slashdot publishes 1,000,000th rumor passed off as actual story. The story generates 480 comments, 263 of which agree with the article, and 107 of which point out its a rumor and are modded down as redundant. The remaining comments are all first posts.
  • 2002. CmdrTaco married to Kathleen Fent. Many geeks believe Kathleen, a purported transvestite, outmeasures CmdrTaco.
  • 2002. Slashdot parent corporation VA Research^W Linux^W Software stock worth 35 cents. Rumors that AOL, Microsoft, or even Jimmy the hobo who lives under the Longfellow Bridge may buy it.
  • 2003. VA Software bought by Microsoft for a cup of coffee and a donut. All Microsoft-critical articles mysteriously disappear from Slashdot. Bill Gates as Borg logo replaced with Bill Gates as God.
  • 2003. Papperatzi videos of Miguel de Icaza caught going down on Bill Gates in his private yacht spread across Usenet. Miguel swears that recent decisions to rename the Gnome desktop to Windows NT 6.0 have nothing to do with it.
  • 2004. CmdrTaco loses hist virginity.
  • 2004. The WIPO Troll returns again, showering Slashdot in 45,000 copies of the same post: Lick my crotch hairs. Slashdot, despite running on 18 redundant IIS/8.0 servers, buckles under the load. The term Slashdotted is replaced with WIPO-Trolled.
  • 2004. Slashdot, the last vestige of VA Research^W Linux^W Software^W Microsoft, officially shut down. Millions of screaming, unwashed geeks invade Redmond campus and lynch Bill Gates. CmdrTaco is believed to posess the only remaining copy of the Slashdot database on several hundred CD-Rs.
  • 2005. The Linux is world is shocked when Linus Torvalds and Anal Cox are found dead along with six penguins, an empty tub of crisco and several used condoms. Millions of screaming, unwashed geeks invade Redmond campus and lynch Steve Ballmer.
  • 2005. CmdrTaco rumored to have had sex again.
  • 2006. CowboiKneel found dead in hotel room with 56 pizza boxes covering his bloated corpse. Three suffocated gay prostitutes are extracted from beneath his body as police remove it with a backhoe.
  • 2007. CmdrTaco actually has sex again. With a woman.
  • 2007. BSD is still officially dying. No word on when its demise will take place.
  • 2007. CmdrTaco starts new weblog to replace Slashdot, creatively named Dotslash. Remainder of Linux users flock to the site and immediate WIPO-Troll it out of existence.
  • 2008. CmdrTaco has sex with his wife for the first time.
  • 2009. After years of living under the heel of his domineering wife, and being deprived of companyof his life-long friend, Jeff Homos Bates, CmdrTaco commits suicide. Another unwashed geek mob gathers and tears Kathleen Fent to shreds. Geeks discover Ms. Fent was indeed a woman, but dont exactly know what that means. Driven by their sexually-repressed rage, they subsequently invade Redmond again and lynch the current CEO of Microsoft, Miguel deIcaza.
  • 2009. Richard Stallman mysteriously murdered. Conspiracy theories run rampant, most involving Microsoft in some way. Invasions of Redmond campus by hordes of geeks become commonplace.
  • 2010. Stallman murder solved when Eric S. Raymond confesses. Raymond blamed the collapse of VA Research^W Linux^W Software^W Microsoft on Stallmans dogmatic insistence on prefixing every open-source project with GNU. Raymond is subsequently committed to an insane asylum, again giving the horde of geeks an excuse to raze Redmond.
  • 2010. An ex-hacker reports witnessing CmdrTaco at a gas station in Tennessee. The nearly-defunct Linux movement is rekindled as CmdrTaco sightings become common.
  • 2011. Microsoft campus burnt to the ground by screaming, unwashed geek mob after Microsoft is blamed when a Linuxhacker in Cambridge, Massachusetts spills his coffee on his pants. Microsoft undaunted as their plans to buy out the Federal Government come to fruition. Washington, D.C. renamed Microsoft Capitol 2010.

"-1", but I laughed out of my ass (1)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220285)

A real pity the subject WAS NOT talking about CmdrTaco, Windows and MS.

We're talking about Linux, 90% of the time.

Some trolls were jewels, though.

This is plain wrong. (5, Insightful)

slasho81 (455509) | more than 12 years ago | (#3220045)

Designing Good Linux Applications

The 'Linux' word is completely unnecessary - "Designing Good Applications" should suffice.
Application design couldn't care less of the OS that the application is planned to run on.

Not totally true... (4, Interesting)

NanoGator (522640) | more than 12 years ago | (#3220133)

I do agree that some of what they talk about in this article would apply to most applications, but not everybody uses an OS the same way. Take this except, for example:

"Everybody loves graphical interfaces. Many times they make our lives easier, and in this way help to popularize software, because the learning curve becomes shallower. But for everyday use, a command at the console prompt, with many options and a good manual, becomes much more practical, making scripts easy, allowing for remote access, etc. So the suggestion is, whenever is possible, to provide both interfaces: graphical for the beginners, and the powerful command line for the expert."

This is wonderful advice in the Linux world. However, most Windows and Mac users, sadly, don't know what a command prompt is, let alone how to script it. This is a native concept to a Linux user.

I have no doubt that even in the Windows/Mac world a really powerful Command Line feature for any given app would be super useful, but it is only so for those who have climed that learning curve. In that case, it's better to focus on making the App do what it needs to do.

In any case, I'm sure I'll draw criticism for that comment. I'd prefer you didn't, though. The point I'm making is that slasho81's comment that all software should be the same despite the OS isn't quite so black and white.

Re:Not totally true... (2, Informative)

Osty (16825) | more than 12 years ago | (#3220162)

have no doubt that even in the Windows/Mac world a really powerful Command Line feature for any given app would be super useful, but it is only so for those who have climed that learning curve. In that case, it's better to focus on making the App do what it needs to do.

In the Windows world, many applications do have powerful commandline features, as well as GUIs. However, you're trying to impose a unix-style of automation (shell script, tying a bunch of small commands together) on a system with its own methods of automation. Let me first say that there are tools you can install on Windows to do unix-style scripting, like Cygwin. I'm ignoring that for now. Typically, when you want to script something in Windows, you'll end up writing some vbscript or jscript that instantiates a COM object and does what it needs through that rather than running an app with some params and catching/piping stdin/stdout. I won't say which method is better, simply that they're different.


This is why *nix administration knowledge doesn't translate to NT administration knowledge, and vice versa. Too often people complain about NT admins trying to use linux or some other unix without ever thinking of the reverse scenario. Try writing a script to force a change of password on next login for some number of NT users. Now make sure it works for local users, NT4 domain users, and Win2K AD users. This is quite doable, but most unix admins look for a passwd-like app, find none, and give up, complaining that NT sucks because they have to go through a GUI to modify 50,000 accounts.

Re:Not totally true... (1)

tomstdenis (446163) | more than 12 years ago | (#3220329)

Sure whatever "bub". I've been using the command prompt since DOS 5.0 [admitedly I am young] and I'd say most MS users then were familiar with the command shell.

Nowadays the average user *does not* need it. The command prompt is still there so who cares?

Tom

Re:This is plain wrong. (0)

Anonymous Coward | more than 12 years ago | (#3220394)

Application design couldn't care less of the OS that the application is planned to run on.

You're right. Next time I write some MS-Windows program, I'll make sure to package it with RPM and not to mess with /usr/local.

As we all know... (0)

Anonymous Coward | more than 12 years ago | (#3220049)

...the best Linux apps are free...and GPL'ed!

Poot (-1)

Serial Troller (556155) | more than 12 years ago | (#3220061)

I'm all over this thread like a PIG IN SLOP.

Designing good Linux applications (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3220072)

Just like cold fusion; it can't be done. If you own x86-family hardware, I recommend Microsoft [netscape.com] Windows XP [windotherm.com] . Otherwise, buy a Mac [macdonalds.com] .

Re:Designing good Linux applications (-1)

Serial Troller (556155) | more than 12 years ago | (#3220099)

Oh, fuck off. Everyone knows the future of computing is Amiga [goatse.cx] .

more FreeBSD applications (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3220074)

The state of computing would be better advanced
if developers would switch to FreeBSD as a more
advanced and stable base.

User friendly? (0)

Anonymous Coward | more than 12 years ago | (#3220096)

User friendly? It might help if the webpage wasn't two screen's wide with no wordwrap.

Re:User friendly? (1, Informative)

Anonymous Coward | more than 12 years ago | (#3220144)

Handy hint - save the html locally. Search for "table 2" and comment the TABLE out. Makes the page readable!

Mmmmnnnn... (1)

MiniChaz (163137) | more than 12 years ago | (#3220127)

Looks like they should consider designing good webpages first. The big tables make the text scroll of the right side of the page for me. Really annoying.

Ohh (0)

Anonymous Coward | more than 12 years ago | (#3220134)

You better do so (i.e. make software linux-centric, tightly kernel-integrated) otherwise interoperability will kill you. Just imagine what would happen if some prog A could run fine on any other platform, why should you use Linux at the end.

Tak Java for instance. It has its own threading model, why every software vendor has to mess up with OS-specific threading models?

I'm happy because at the end you will realise that you have to not just clone Microsoft's software, but its ideas too!

Re:Ohh (1)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220320)

Why should we use Linux? A lot of powerful GPL'ed tools.

To examplify, if we're using Linux to execute "some prog A" we may build clusters running Linux so we get most of the software. Memory management under Linux is on par to Win2k if it's not better. Who want a real professional execution of a desired application should stick with Linux.

/usr/local is obsolete (0)

Bongzilla (458471) | more than 12 years ago | (#3220146)


well, tarnation! :o)

that sounds suspicious to me.

A couple more tips: (0, Funny)

Genghis Troll (158585) | more than 12 years ago | (#3220148)

Try to use the word "fuck" in your code:

[mojo]:/usr/src/linux :grep -ir fuck *
Documentation/DocBook/kernel-locking.tmpl: If you don't see why, please stay the fuck away from my code.
Documentation/DocBook/kernel-locking.tmpl: <title>The Fucked Up Sparc</title>
arch/i386/kernel/mtrr.c:/* Some BIOS's are fucked and don't set all MTRRs the same! */
arch/sparc/kernel/head.S: /* XXX Fucking Cypress... */
arch/sparc/kernel/process.c: /* fuck me plenty */
arch/sparc/kernel/sunos_ioctl.c: /* Binary compatibility is good American knowhow fuckin' up. */
arch/sparc/kernel/ptrace.c:/* Fuck me gently with a chainsaw... */
arch/mips/kernel/irixelf.c:#if 0 /* XXX No fucking way dude... */
arch/mips/kernel/irixioctl.c: * irixioctl.c: A fucking mess...
arch/mips/sgi/kernel/setup.c: * fucking with the memory controller because it needs to know the
arch/sparc64/kernel/process.c: /* fuck me plenty */
arch/sparc64/kernel/traps.c: /* Why the fuck did they have to change this? */
arch/sparc64/kernel/binfmt_aout32.c: /* Fuck me plenty... */
arch/sparc64/mm/init.c: /* Fucking losing PROM has more mappings in the TLB, but
arch/mips64/sgi-ip22/ip22-setup.c: * fucking with the memory controller because it needs to know the
arch/parisc/kernel/signal.c: printk("fuckup in sys_rt_sigreturn, sending SIGSEGV\n");
arch/parisc/kernel/signal.c: /* ARGH! Fucking brain damage. You don't want to know. */
arch/parisc/kernel/signal.c: printk("fuckup in setup_rt_frame, sending SIGSEGV\n");
drivers/net/sunhme.c:/* Only Sun can take such nice parts and fuck up the programming interface
drivers/net/sunhme.c: /* This card is _fucking_ hot... */
drivers/char/drm/drmP.h:extern int DRM(release_fuck)(struct inode *inode, struct file *filp);
drivers/scsi/esp.c: * how bad the target and/or ESP fucks things up.
drivers/scsi/esp.c: * phase things. We don't want to fuck directly with
drivers/scsi/esp.c: /* Be careful, we could really get fucked during synchronous
drivers/scsi/qlogicpti.h:/* Am I fucking pedantic or what? */
drivers/scsi/NCR53C9x.c: * how bad the target and/or ESP fucks things up.
drivers/scsi/NCR53C9x.c: /* Be careful, we could really get fucked during synchronous
drivers/sound/aci.c:/* The four ACI command types are fucked up. [-:
drivers/cdrom/sbpcd.c: blkdev_dequeue_request(req); /* task can fuck it up GTL */
drivers/ide/cmd640.c: * These chips are basically fucked by design, and getting this driver
fs/binfmt_aout.c: /* Fuck me plenty... */
fs/jffs/intrep.c: don't fuck up. This is why we have
fs/intermezzo/presto.c: printk("fucked dentry: %p\n", dentry);
include/linux/netfilter_ipv4/ipt_limit.h : /* Ugly, ugly fucker. */
include/linux/netfilter_ipv6/ip6t_limit.h: /* Ugly, ugly fucker. */
include/asm-mips/mmu_context.h:/* Fuck. The f-word is here so you can grep for it :-) */
include/asm-sparc64/system.h: /* If you fuck with this, update ret_from_syscall code too. */ \
include/asm-mips64/unistd.h:/* These are here for sake of fucking lusercode living in the fucking believe
include/asm-mips64/unistd.h: having to fuck around with the syscall interface themselfes. */
include/asm-parisc/spinlock.h: * writers) in interrupt handlers someone fucked up and we'd dead-lock
lib/vsprintf.c: * Wirzenius wrote this portably, Torvalds fucked it up :-)
net/core/netfilter.c: /* James M doesn't say fuck enough. */
net/ipv4/netfilter/ip_conntrack_core.c:/* This is fucking braindead. There is NO WAY of doing this without
net/ipv4/netfilter/ipt_limit.c: * Alexey is a fucking genius?
net/ipv4/netfilter/ip_nat_helper.c:/* Grrr... SACK. Fuck me even harder. Don't want to fix it on the
net/ipv4/netfilter/ip_nat_snmp_basic.c: * (And this is the fucking 'basic' method).
net/ipv6/netfilter/ip6t_limit.c: * Alexey is a fucking genius?

If you can't work "fuck" in, then try for "shit", "cock", "ass", or even "penis". These words are all also found in the linux kernel source. There are, of course, no references to "pussy", "vagina", "cunt", or even "clit".

Re:A couple more tips: (-1)

Serial Troller (556155) | more than 12 years ago | (#3220213)

I wish you included line numbers there. grep -inr, man.

rtwsdefag jhg fjhgfhjjhg jhkj hgkjh (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220158)

sfdsjl hhghj g 6r5ertr lh klkjhkjhjgjhfg jkhyit trtyeee r 6r6oo 8o 98778t7tt 77t8ul. tu trt rftyyyy dgj jh jhkil ygyiiiiiiitg hjf gfgh ghfj hh 78t87 68787iul hjg jjh gkfhg fhhgdfgd gfdgf jgjkliuyiuy77778t78 6t 6tredrdtrdgfd ghf7887 ygjh gjjhjhljkghjgjkhgfdfgdgsdfsfd hghghfjhfhh jjj hjjjjjhgfhgfhg hf

Name: CmdrTaco [ Log Out ]
URL http://slashdot.org/
Subject:
Comment sfdsjl hhghj g 6r5ertr lh klkjhkjhjgjhfg jkhyit trtyeee r 6r6oo 8o 98778t7tt 77t8ul. tu trt rftyyyy dgj jh jhkil ygyiiiiiiitg hjf gfgh ghfj hh 78t87 68787iul hjg jjh gkfhg fhhgdfgd gfdgf jgjkliuyiuy77778t78 6t 6tredrdtrdgfd ghf7887 ygjh gjjhjhljkghjgjkhgfdfgdgsdfsfd hghghfjhfhh jjj hjjjjjhgfhgfhg hf
(Use the Preview Button! Check those URLs! Don't forget the http://!)
No Score +1 Bonus Post Anonymously
Plain Old Text HTML Formatted Extrans (html tags to text) Code
Allowed HTML:



    • Important Stuff:
      Please try to keep posts on topic.
      Try to reply to other people comments instead of starting new threads.
      Read other people's messages before posting your own to avoid simply duplicating what has already been said.
      Use a clear subject that describes what your message is about.
      Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

With any luck... (5, Interesting)

Nailer (69468) | more than 12 years ago | (#3220174)

This will get round to people making the applications. I'm absolutely fed up with people, especially vendors of proprietary software, making nonstandard software. In my book, standard (LSB) Linux apps are the *only* Linux apps, this means:
  • They are packaged as RPM 3 files, to allow standard installation, deinstallation, auditing, and management of relationships with other necessary software. Not some interactive self extracting tarball I can only use once unless I do the vendors job and package it myself (which unfortunately is necessary for modern sysadmins if they want to do their job properly).
  • They use SysV init scripts which live in /etc/init.d. Again, I often have to do the vendors job for them and write the initscript myself. This sucks, I paid my money for a Linux app and I want a Linux app. This means you Sophos Mailmonitor.
  • General FHS compliance. I should be able to mount / readonly and /var read write and your app should work, once I have configured it. This is too often not the case. This means you StarOffice.
  • Man pages should always exist (no, not `Debian tells me I need a man page so this is it, I have no actual useful content, write me!' man pages but actual real no-bullshit man pages. Man pages go in /usr/share/man.

  • Documentation in /usr/share/doc. Not in /usr/lib. Yes, the FHS says you can install non-user executed binaries in /usr/lib, but documentation is not libraries or binaries, never was, and never will be. This means you Citrix.
  • Die symlinks, die. Linking correct locations to their incorrect locations should be as short term as possible. Yes, this means you Red Hat. Reverse the /etc/init.d -> /etc/rc.d/init.d symlinks now.
  • UNLESS YOU ASK MY EXPLICIT PERMISSION TO INSTALL EACH FILE SUSE OR ANY OTHER DISTRO HAS NO RIGHT TO DO THINGS TO MY /OPT. Aaaarrgggh Suse!

There will be things you don't like about the LSB and FHS. Personally, I reckon initscripts aren't config files and should live in /sbin. But I put them in /etc/init.d because the FHS says I should. Likewise, if you have a problem with RPM, make it better (apt-get's already a basis for all my Red Hat installs and updates thanks to Freshrpms).

Re:With any luck... (1)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220220)

I had Red Hat 6.2 loaded with an obsolete RPM version that prevented me to install several packages.

Is amazing that Red Hat distributions were a *bit* similar to Windows sometimes.

An app which needs to be updated for making other apps to work.

Oh, maybe I'm exaggerating too much. No matter if you're using LSB or RHS you've to deal with libc's, gcc's and glibs' versions.

Thank God GIMP works with plug-ins!

Re:With any luck... (2)

Nailer (69468) | more than 12 years ago | (#3220236)

I had Red Hat 6.2 loaded with an obsolete RPM version that prevented me to install several packages.

You can run `up2date -u' to download the newer version of RPM and all necessary security / bugfixes for Red Hat 7.2, plus their dependencies.

Re:With any luck... (2)

Nailer (69468) | more than 12 years ago | (#3220251)

You can run `up2date -u' to download the newer version of RPM and all necessary security / bugfixes for Red Hat 7.2, plus their dependencies.

I meant 6.2 (and yes, up2date works in 6.2).

Re:With any luck... (0)

Anonymous Coward | more than 12 years ago | (#3220332)

Little correction:

> # They use SysV init scripts

From fhs 2.2:

4. The setup of command scripts invoked at boot
time may resemble SystemV, BSD or other
models. Further specification in this
area may be added to a future version of
this standard.

Nick.

Re:With any luck... (2)

proberts (9821) | more than 12 years ago | (#3220401)

> # They are packaged as RPM 3 files, to allow
> standard installation, deinstallation,
> auditing, and management of relationships with
> other necessary software. Not some interactive
> self extracting tarball I can only use once
> unless I do the vendors job and package it
> myself (which unfortunately is necessary for
> modern sysadmins if they want to do their job
> properly).

No *nix is an island. RPM isn't the norm on even all Linux systems, let alone the rest of the *nix world. Don't forget that the x86 BSDs run Linux binaries too. Chaining dependencies like package managers and package management databases makes it more difficult for a lot of people who don't really need the overhead. The point of distributions is to allow someone to package software for it- so it's really the distributor's job to package for a specific package manager, not the vendor.

Paul

Re:With any luck... (2)

Skapare (16644) | more than 12 years ago | (#3220423)

Not some interactive self extracting tarball I can only use once unless I do the vendors job and package it myself (which unfortunately is necessary for modern sysadmins if they want to do their job properly).

If you already have the tarball, why are you trying to make a different package out of it? Don't forget that many applications are made for a variety of different systems. Linux isn't everything out there.

They use SysV init scripts which live in /etc/init.d. Again, I often have to do the vendors job for them and write the initscript myself. This sucks, I paid my money for a Linux app and I want a Linux app. This means you Sophos Mailmonitor.

I'll agree that it is annoying to have packages making assumptions about where they put boot scripts. But Linux is about choice. There is more than one standard to choose from. Sounds to me like you are trying to make cookie cutters.

Die symlinks, die. Linking correct locations to their incorrect locations should be as short term as possible. Yes, this means you Red Hat. Reverse the /etc/init.d -> /etc/rc.d/init.d symlinks now.

I hate symlinks, too. I want to get rid of all the symlinks in the whole /etc/rc.d. And guess what ... I did!

Hey.. (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3220201)

You know what sucks? Vacuums.

Re:Hey.. (-1)

GafTheHorseInTears (565684) | more than 12 years ago | (#3220272)

You know what else sucks? Your mom.

My two cents: (2, Informative)

colmore (56499) | more than 12 years ago | (#3220202)

So I'm not a developer, and I don't know that much about programming. (Teaching myself QT 3 for the heck of it, but can't really do much worthwhile)

Anyway here would be my two suggestions:

1) Quit ripping off Microsoft and Apple. or at least think before you do. Using any Linux GUI you can immediately see the areas where the team said "lets make this more like Windows." on the one hand, this makes things more familiar and easy for the new users, but on the other hand, it repeats a bunch of bad and arbitrary GUI conventions that should be re-examined. For instance, in Mozilla by default, there's the same irritating password remember feature as in IE. This should not be a default-on option, the security risk is huge, whoever made that mistake at MS ought to be fired. Why do we continue it?

2) Drop the in-jokes please. Calling everything "GNU-" putting funny little things in the help files etc. etc. etc. we want to convince people that we're making a professional quality product. And nothing spoils that faster than giving the appearance of a hack.

and my suggestion to the non-developing members of the community would be:

spending some of your time filling out bug reports and posting (well thought out, politely worded) suggestions is much more effective than posting "linux roolz" on public news services.

here on Slashdot we like to speculate that Microsoft has hired a group of people to spread anti-opensource FUD in our midsts. the lamers who do nothing but insult "Micro$oft" all the time are the free equivalent.

Re:My two cents: (1)

CanadaDave (544515) | more than 12 years ago | (#3220238)

"Quit ripping off Microsoft and Apple"

People always talk about this, but me, being a former Windows user, found switching to Linux so much easier because of the similarities. I think KDE for example has copied Windows a heck of a lot, but they've also done their own thing in many respects. I think making GUI's even more customizable would solve this problem. But Linux is already very customizable. If you try hard, you can make it look nothing like Windows. Or use one of the older UNIX-style window managers.

"Drop the in-jokes please"

I kind of like that kind of thing. It makes me think that real people actually made the stuff. On those same lines, I also like being able to e-mail the developer that made such and such a program. If there is a major bug that I spot, I can let him know, or I can just say what I like and don't like about his program.

"spending some of your time filling out bug reports and posting"

Yes! This is super important. I just got involved with doing this, mostly with Mozilla and OpenOffice. It takes a lot of my time away from studying, but it's fun!

Re:My two cents: (1, Insightful)

Anonymous Coward | more than 12 years ago | (#3220305)

Lighten up. The OS mascot is a penguin for gods sake.
Pros use it because it's good, not because the
documentation was written while wearing a tie.

Re:My two cents: (1)

NinjaGaidenIIIcuts (568607) | more than 12 years ago | (#3220344)


My two cents

Let's factuate it, Linux doesn't worth any cents. Linux is free :-)

On GCC and others of the same ilk. (2, Interesting)

yeOldeSkeptic (547343) | more than 12 years ago | (#3220212)

I agree with the main thesis of the article. I just wish more packages follow the ideas expounded, and specially the FHS.

For example, gcc when installed from source defaults to putting itself into /usr/local/ which is quite understandable, because it was locally installed. Unfortunately libgcc_s.so should have placed itself in /lib instead of /usr/local/lib because some boot-time binaries need it. (modutils if I recall correctly.) The first time I installed gcc from .tar.gz, my sysinit crashed because /usr wasn't mounted yet.

Other packages have this problem too: fileutils, bash and modutils come to mind. The default configuration is to install themselves into /usr/local/ despite the fact they are needed during boot. (init's message of "rm: no such file" puzzled me the first time I saw it.) Now, I know that ./configure --prefix=/ fixes those things, but my point is, the user shouldn't have to learn from experience how to correctly install those packages. The packages should help him.

Re:On GCC and others of the same ilk. (2, Informative)

jdh28 (19903) | more than 12 years ago | (#3220336)

I think the reason GNU stuff defaults to /usr/local is because it comes from a background where most people would be installing the GNU utilities on UNIX systems that had vendor supplied utilities like rm, etc.

john

Designing applications, hardware (1)

HowlinMadMurphy (568726) | more than 12 years ago | (#3220223)

It was GIL AMELIO who nearly killed Apple! It was all Power Computing to do to keep people buying any kind of Mac at all!!

And Power did their own R&D, thank you. Sure, they ripped off most of the early MLB layouts, but after Alchemy, the boards were all Power's own. And they were adding the features Mac users wanted -- like faster bus speeds and modern RAM. Not to mention decent video performance. Power was doing the Mac community a favor by getting the RAM ceilings out of the double digits.

If Apple was happy with less than 1% of the total PC market, then fine. Because when it comes right down to it, to hell with Apple. I go to Apple's computers because they're the best, but at that time, they weren't. The best you could get was some 8100 piece of shit and THEN what, you're stuck with Nubus expansion and a lot of proprietary video hardware. Meanwhile, Power was producing cutting-edge machines... some of which had hardware on them that wasn't even available for PCs yet.

Power gave half a shit about producing USEABLE machines, made they way they were supposed to be made. Meanwhile, Apple was sitting around being weak and spineless. They got scared when the market was getting away from them, and so they yanked the licenses and killed the baby.

I know a guy who was at the top levels of Power's Technical Response department. (His business card said "Grand Technical Czar."). I know at an intimate level what was going on at Power, and it was not any kind of plotting effort to undermine Apple's success. They just didn't give a *fuck* about all the pissy little things that were wasting Apple's time. Most of the people working for my friend were recruited from Apple, where they were disgruntled and lethargic. But at Power, they found renewed energy for not Apple, but the Macintosh platform. And they made it better than any other out there. By the time Power closed, their machines were running not just MacOS, but BeOS and LinuxPPC as well. Would that have happened with Apple getting in the way on things like bus speeds and cache sizes? While Apple was making machines that didn't have caches, Power was redeveloping the whole concept. We have Power to thank for the Backside Level 2 Cache technology, don't forget that.

The clones were all that keps Apple alive through its darkest time. Thanks to power in particular, there are now more Mac die-hards than ever, and the mac has made tremendous progress in its technology and features thanks to people like those who used to work at Power.

If anyone's to blame for Apple's problems, it's Apple.

Why don't they follow their own advice ?? (1)

FinnishFlash (414045) | more than 12 years ago | (#3220225)

This article is actually really good ! Read it !

Strangely enough, all IBM software that I've had the pleasure to deal with (DB2, IBMHTTP and Websphere) try to install themselves by default to /opt..

/opt vs. RPM (4, Insightful)

HalfFlat (121672) | more than 12 years ago | (#3220247)

The author states that /opt is obsolete, and that everything should use RPM and install in /usr. Maybe this is the ideal in a system where everything is binaries-only, but I firmly believe it is poor administration practice.

The RPM database is binary and fragile. Once it is corrupted, the data describing what belongs to what goes out the window. RPM-packages have to be trusted not to clobber existing files or make changes to configuration files that one wants left alone. The alternative is per-application directories and symlinks (or a long PATH variable); there are tools which automate this, such as stow. The advantage is that the file system is - or at least should be - the most stable thing in the system. One can just examine a symbolic link to see what package it belongs to. This makes removing and updating applications very easy, and also makes it easy to see if there are any links left around from older installations. Removing an application is typically as simple as removing the corresponding application directory.

RPMs which install in the /usr tree will require root priviledges, whereas applications that can work from a self-contained directory can be installed by a non-priviledged user in their own directory, Also, /usr in principle can be mounted read-only. This will certainly slow down any attempts at installing software in it!

I have had Redhat's installer corrupt the RPM database on multiple occasions; and I've had to override the dependancy checking innumerable times in attempts to update packages under both Redhat and SuSE, thus rendering useless the other purported benefit of RPM. New software typically comes in source form before RPMs; and the RPMs that do become available are almost always going to be third-party ones that don't necessarily play well with your system. By the time a vendor-created RPM becomes available, the distribution version you are using is no longer actively supported, and you'll need 300MB of updates to other packages just to satisfy dependencies. I've been there, it's horrid.

OS X app bundles, NOW!!! (1)

Ilan Volow (539597) | more than 12 years ago | (#3220309)

I agree totally with the idea of RPM's scheme being stupid and dangerous. I'd like to see linux adopt a feature similar to OS X application bundles, where all the stuff associated with an application is put into a single folder (*.app) that is represented as the application itself. This is a hell of a lot more sturdy than relying on a binary database to say what belongs to what application.

Re:OS X app bundles, NOW!!! (2)

Chainsaw (2302) | more than 12 years ago | (#3220362)

Bingo. This is a point where the Mac - or should I say NextStep - made something very correct. Installing an application found online is a simple process in three stages: download, double-click to unpack from .tar.bz2, move it to the /Applications or ~/Applications folder. Removing it is equally simple: delete the application and *poff* it's gone.

Why hasn't this been adopted by the Unix community? It's just some special treatment of a damned folder! What else is needed for you to accept this solution?

Init levels (1)

blueswan (171061) | more than 12 years ago | (#3220256)

How did run level 5 get chosen as the graphical login level, and is that why the linux admins keep powering my sparcs down?

the only good linux application (4, Insightful)

mmusn (567069) | more than 12 years ago | (#3220259)

is a command line application.

Seriously, a lot of Linux applications try to duplicate the Windows world and end up being just as bad. For example, for audio software, a monolithic executable with GUI is a Windows-style application--hard to reuse, hard to extend. A bunch of command line applications that can be piped together and come with a simple scripted GUI, that's a good Linux application because its bits and pieces can actually be reused.

My articles on software quality (2)

goingware (85213) | more than 12 years ago | (#3220260)

I have great ambitions for the Linux Quality Database [sunsite.dk] which are so far mostly unfulfilled, but for now I have some articles which you may find worthwhile reading:

Also if you program in C++, these articles may be useful:

shame they can't design good web pages (1)

CProgrammer98 (240351) | more than 12 years ago | (#3220277)

the article is horribly formatted, I HATE IT when you have to maximize your browser window and STILL have to scroll right to read the text. HORRIBLE HORRIBLE HORRIBLE.

Re:shame they can't design good web pages (1)

Inferno666 (568675) | more than 12 years ago | (#3220323)

Yes i definetly concur, I'm even running in 1600x1200 with Fullscreen IE, and i have about 3 inches to scroll over.

Think outside the Linux box (5, Insightful)

Oink.NET (551861) | more than 12 years ago | (#3220279)

This guy's ideas would be way more useful if he could think outside the stereotypical structure of today's Linux apps.

Ditch the concept of spreading pieces of your app all around the FHS. This is organizationally similar to Microsoft's registry. It becomes a maintenance nightmare. Yes, RPM keeps track of some pesky details that let us get away with a messier install. Yes, the FHS does impose a common structure on what is an otherwise unstructured mess. But programmers are human beings, subject to the whims of ego, ignorance, and yes, even creativity and sheer brilliance. We're going to deviate from the suggested standards if given the opportunity, for one reason or another.

Give me one main point of access to everything the application does. If you need to use config files, give me the option of manipulating them through the application itself, preferably in the context of my current task. Give me one place to go looking for all the bits and pieces of the app. No, the FHS isn't simple enough. Give me context-sensitive documentation so I don't have to wander outside the app to get my job done. Don't make me wade through a spaghetti-code config file, with the documentation propped open on a separate screen to keep from getting lost.

Programmers are lazy. I should know, I am one. The last thing I want to do when I'm getting ready to release a program to non-techie users is tie up all the loose ends that seem ok to me, but not to the non-techie user. I'd rather document how to get a tricky task done than write the code that automates the tricky parts. I'd rather tell the user how to go tweak the flaky data in the database by hand than add another error-correcting routine. And it's more work to give the user one simple, full-featured point of entry to each piece of a complex application. But that additional work will make the application more usable, for the expert and the novice alike.

The quote of the moment (4, Funny)

Faux_Pseudo (141152) | more than 12 years ago | (#3220301)

That's the thing about people who think they hate computers. What they really hate is lousy programmers. - Larry Niven and Jerry Pournelle in "Oath of Fealty"

That is what I found in the fortune at the bottem of the this thread.

worst thing I've read this month (1)

software_non_olet (567318) | more than 12 years ago | (#3220322)

This great guy (I'm not going to use his name, no M'am) tells a Linux readership that RPMs should be used, that directories for binfiles, configfiles, data and logs help acceptance of your software - huh? And at the same time he is not able to apply his great separation of content from configuration to his own paper?

And what's the content? A paper how to package Linux-applications - for mainframers who just have their second day of "introduction to Linux for programmers who did up to now think, that CPU-speed is measured in kilo-tons".

Instead of bogomips, of course .o)

drop FHS, please ? (0)

Anonymous Coward | more than 12 years ago | (#3220338)

The whole idea of spreading files here and there is what causes all the problems. Why don't use the filesystem properly ? Each app should be in its own directory. Stuff that must be shared between apps should still reside in the originating app directory, hard-linked though in a pre-known folder. Example :

(since I don't know HTML get the following tree and paste it in an editor with a fixed width font)
/ (root)
|
|--apps
| |
| |--StarOffice
| |
|-SharedLib.so
|-StarOffice.ini
| |--SendMail
| |--MySQL
|
|
|--CommonExe
| |
| |-SendMail.bin
| |-MySQL.bin
| |-StarOffice.bin
|
|--CommonLibs
| |
| |-SharedLib.so (hard link)
|
|--CommonConfigs
|
|-StarOffice.ini (hard link)

So each time 'SendMail' or 'MySQL' want to use 'SharedLib.so', they do so by using '/CommonLibs/SharedLib.so'.

Suppose now that I want to move the StarOffice app around. What would I do ? grab it with the mouse and drop it in the new destination folder. But the rest of the apps that are based on StarOffice still work, because they find things through common folders.

Suppose that I want to install a new app : just unzip it in the Apps folder and hard link all common stuff in the regular common directories.

Suppose I want to uninstall some stuff : just wipe out the directory of the App! hard links will be around, but the uninstaller would wipe out these hard links automatically!

No need for registries, scripts, etc, etc.

And if the config files had a common format, there could be a universal tool that handles all those in a pre-known directory.

It is silly to have stuff around when you can have it hard-linked from one source.

Designing Linux Applications (2, Funny)

zapfie (560589) | more than 12 years ago | (#3220375)

Designing good Linux applications is easy as 1, 2, 3. Just follow these simple steps.

1) Command line only. We all know real users only use command line.
2) Don't comment your source code. Ever. It just wastes valuable programming time.
3) No installation/usage documentation. If they deserved to use your app, they can go figure it out themselves. What are you, tech support?

If you follow these simple instructions, you are guaranteed a rabid cult following, or at the very least a feeling of superiority over your users.
</sarcasm>
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>