Slashdot: News for Nerds


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!

Heavy-Duty System Administration Utilities?

Cliff posted more than 10 years ago | from the more-transactions-than-you-can-shake-a-stick-at dept.

Software 44

leandrod asks: "I am in the process of helping a small software company define the infrastructure for their major client's new system. It is a big country, and it is a medium-sized client planning on going big. We are planning to standardize on Debian GNU/Linux. I am aware I can have IBM Tivoli Maestro for GNU/Linux for production scheduling, and BEA's Tuxedo TP monitor, but they are unsupported under Debian. I am also aware of one or two free TP monitors, but they are either incipient or stagnating. I couldn't find a production scheduler. I know I can do lots with the standard tools, but keep in mind I am targeting a transaction-processing bureau for a big operation with hundreds of thousands of terminals and millions of users, something like a poor man's Wal-Mart, or even Visa. Are there vendors out there willing to support Debian or just GNU/Linux in general? If not, are there free software projects that accomplish the same thing?"

cancel ×


Support (2, Interesting)

!3ren (686818) | more than 10 years ago | (#8266737)

Perhaps this major client could fund development/maintenance on a missing piece of infrastructure.

Think long-term stability... (4, Insightful)

duffbeer703 (177751) | more than 10 years ago | (#8266738)

Standardizing on Debian is a really lousy idea. At some point, your customer is likely to need or want commercial software (esp RDBMS), and they will find that Debian is simply not supported by any commercial software vendor. (To be honest, most non-Linux geeks have never heard of Debian)

Go with Red Hat or Suse. You might find that going with a more stable (from a support POV) Unix OS like Solaris may be a good choice for certain systems as well. The support costs are real, but a Tivoli Management environment would cost a helluva lot more if the IBM salesfolk talk your client into it.

If you in a signifigant transaction processing business, the money will come - spend the money now to start a Maestro or Tuxedo system so you don't need to waste valuable time (and lose business) later.

I also hate to say this a longtime Debian fan... but the major commercial distros aren't going anywhere. RedHat and Suse have built brands and have major money & support flowing in from corps like IBM & HP. Can the same be said for Debian, whose stable release is starting to get a little crusty?

Remember to ask yourself what you & your client needs and what is best for the business. Keep the tech-geek religious wars on Slashdot!

Re:Think long-term stability... (2, Informative)

cybermace5 (446439) | more than 10 years ago | (#8266781)

One interesting addendum to the above: SUSE Linux to receive international EAL2 rating [] . Since SUSE is owned by Novell now, it also has the backing of a company that had, at least some time ago, the most popular network suite in corporations. Still in use a lot of places, actually.

Re:Think long-term stability... (3, Funny)

the_other_one (178565) | more than 10 years ago | (#8266810)

Debian is commercial software. For hundreds of thounsands of terminals, we at SCO, will be happy to provide invoices.

Re:Think long-term stability... (2, Interesting)

BladeMelbourne (518866) | more than 10 years ago | (#8266849)


Debian packages are too old, unless you want to jump into the "unstable" tree - and what business can accept unstable server software? Back-porting bugfixes just don't cut it in the business world. Debian lacks a powerful entity that governs development priorities - but it doesn't lack zealots who will die for their cause.

For example... Debian hasn't got XFree86 4.3.0 in their stable tree (and they wont for years to come as they still have 4.1.0 stable) - whereas RedHat has had a stable XFree86 4.3.0 for over a year. RedHat isn't perfect - but more often than not it's more suitable for business useage.

Rick Moen can't grasp this.

Re:Think long-term stability... (4, Funny)

swillden (191260) | more than 10 years ago | (#8267326)

Debian packages are too old, unless you want to jump into the "unstable" tree - and what business can accept unstable server software?... For example... Debian hasn't got XFree86 4.3.0 in their stable tree (and they wont for years to come as they still have 4.1.0 stable)

Right. Everyone knows that you absolutely cannot run a large-scale production server effectively without the new features in XFree86 4.3. It's obvious that 4.1 just doesn't cut it when you have millions of transactions to process... I mean, it can't even change the screen resolution on the fly!

Re:Think long-term stability... (3, Informative)

Drakon (414580) | more than 10 years ago | (#8267675)

I mean, it can't even change the screen resolution on the fly!

ctrl+shift+(numpad Plus/minus)

Re:Think long-term stability... (1)

swillden (191260) | more than 10 years ago | (#8268624)

ctrl+shift+(numpad Plus/minus)

Right. To be precise, it can't change the desktop size on the fly.

Re:Think long-term stability... (2, Interesting)

duffbeer703 (177751) | more than 10 years ago | (#8268880)

You're missing the point. X is an obvious example, there are plenty of others.

Re:Think long-term stability... (2, Interesting)

Anonymous Coward | more than 10 years ago | (#8270843)

> You're missing the point. X is an obvious example, there are plenty of others.

He's hardly missing the point, you are.

New-featured software is NOT what a production business server needs. Such servers need stable, well-tested software that is patched for security and serious functional problems - but NOT constantly enhanced with new features that contain their own set of new bugs. The idea of business server software is to gradually approach a bugfree state - and you don't get that by constantly adding new features, you get that by patching the existing software.

It's called Debian stable for a good reason.

Re:Think long-term stability... (3, Informative)

swillden (191260) | more than 10 years ago | (#8274971)

X is a *bad* example, easily attacked, but your argument is fundamentally wrong. The goal with production servers is stability and security, and the Debian stable approach is the hands-down best way to achieve that (though simply running stable isn't enough, it's a good start).

The only valid reason to upgrade production software is if you must have the features available in the new version, or if you can no longer get support for the old version. Outside of that, you keep what works. Debian stable is very well-supported and it's never more than two or three years behind the cutting edge. It's really ideal, with the caveat mentioned up a few posts that if you need to run closed source commercial software, you will get much better support on Red Hat and SuSE.

Re:Think long-term stability... (1)

Mr. Piddle (567882) | more than 10 years ago | (#8269793)

Can the same be said for Debian, whose stable release is starting to get a little crusty?

There is a lot of popular support for Debian. Also, there are people out there who apprciate the crustiness as a tradeoff for the higher chance of it working well. Further, Debian has one of the more flexible installation programs out there (/cdrom and /target can be NFS mounts during an install, for example, which is _extremely_ useful).

Re:Think long-term stability... (1)

Wolfrider (856) | more than 10 years ago | (#8280788)

--Now that's got me thinking.

Could you:
o Add /cdrom to client sources.list

o Mount another (server's) /var/cache/apt NFS on /cdrom (R/O) ...and have that as a centralized package server?

Re:Think long-term stability... (1)

qtp (461286) | more than 10 years ago | (#8287337)

At some point, your customer is likely to need or want commercial software (esp RDBMS), and they will find that Debian is simply not supported by any commercial software vendor.

What about MySQL [] , or do you not consider them to be "comercial" because their support offerings are optional and you can use their product for free if you choose to? MySQL offers comercial support to any and all who use their product, regardless of the platform you've installed it on (even Windows!), but of course you'll have to get your .debs from Debian, even if you do plan on using MySQLs support offerings..

Or you can use PostgreSQL [] on Debian and get your support from PostgreSQL Incorporated [] , but only if you're truly interested using using a reliable, and standards compliant database available (for raw performance, you'll want MySQL).

I understand your point, but it simply is not true that there is no commercial support [] for Debian (and that list is sorely incomplete). Yes, it is best if at least one person in your company take the time to become familiar enough with Debian to handle problems on their own, but that is true no-matter what OS you are using. If the consultant is most familiar with Debian, and Debian provides the capabilities needed by the client, then there is little reason not to use Debian.

Re:Think long-term stability... (1)

duffbeer703 (177751) | more than 10 years ago | (#8290755)

How about database clustering?

Or remote replication?

Or security and access roles compatible with HIPPA regulations?

Or reliable data recovery compatible with large-scale backup systems like Legato or TSM or Veritas?

MySQL cannot do these things. A RDBMS like DB2 or Oracle can deliver an incredible amount of value for certain applications, particularly things like high-volume transaction processing.

You need to use the right tool for the right job. MySQL is the right choice for alot of database applications... but certainly not all of them.

And btw when I say "commercial support", I'm not talking about technical support. I'm talking about application compatability. As an example, DB2 v8.1 is built at specific distributions of Red Hat, Suse and TurboLinux.

Subtle differences in glibc version, the version of gcc the distro was built with or kernel changes can easily break binary distributions of software, so IBM won't support DB2 on Mandrake Linux or Debian or whatever...

Re:Think long-term stability... (2, Informative)

cloudmaster (10662) | more than 10 years ago | (#8295210)

How long has it been since you looked at MySQL's features?

How about database clustering?

I'm not sure about that one - but it seems like either regular replication or 2-way replication oughtta get those needs taken care of. Or, read This article []

Or remote replication?

Replication in MySQL [] is easy - I'm running a couple of replicas right now for backup purposes

Or security and access roles compatible with HIPPA regulations?

MySQL's access control can grant and deny access down to the column level. I assume that you mean HIPAA, though, and any access control problems introduced can be handled by the developer planning the database / managing access control, given MySQL's pretty granular control abilities. The job of managing HIPAA-compliant access control should be at the application level and not the database level, anyway.

Or reliable data recovery compatible with large-scale backup systems like Legato or TSM or Veritas?

MySQL uses files and directories that *any* backup system can use, even those that cost lots of money. Want a backup? Lock the table, dump the table, unlock the table. It's not hard. Read more about backing up MySQL [] . It doesn't get much more reliable than that.

I have a replicated, reliably backed up pair of mysql servers behind me. They're not HIPAA compliant, because that's a pain, but it'd be largely trivial to implement. Com back when you've researched your gripes.

Re:Think long-term stability... (1)

afidel (530433) | more than 10 years ago | (#8301130)

Sorry but the question poster is talking about a VERY high volume OLTP operation, no one in their right mind would use MySQL in such an environment. There are only two choices for such an environment, Oracle and DB2, anything else is just being stupid. IBM supports DB2 on a pretty wide range of linux distro's but Debian isn't one of them. For a large enough client they might sell a support contract for a non-listed environment (since some of those systems listed are fairly oddball I assume that's how they got on there). Btw locking and dumping a table is NOT an option in a real 24x7 OLTP environment.

Re:Think long-term stability... (1)

cloudmaster (10662) | more than 10 years ago | (#8305582)

I agree that in a critical environment MySQL probably wouldn't be the first choice. However, it's not because of any of the reasons given by the person I replied to. :) Then again, I can't think of any other good reasons. Have you got one (other than "it's free, and therefore must not be as good as something expensive")? ;) The write speed isn't as good as some other DBs (MySQL's better at reading than most DBs), but I'm pretty confident that it'd be acceptable - esp since it'd presumably be behind some kind of load balancer anyway (see link in previous post).

Exposing some of my own ignorance here, though: I am somewhat curious how one can achieve a backup (aka a dump) of a table that's consistent without somehow stopping writes momentarily. Can't take a snapshot if the data might change while generating the snapshot... I do my backups (in a 24x7 environment) from a replica anyway - so nothing's hurt by locking the tables for a while, since the master's still available for writing and the replcation logs just get deferred for a moment. Presumably a "real" install would have more than just the single db server...

Sun's N1 (2, Informative) (562495) | more than 10 years ago | (#8266786)

Check out Sun Microsystem's N1 Grid [] .
I hear Sun offering suport for Linux as well, these days

Re:Sun's N1 (2, Informative)

afabbro (33948) | more than 10 years ago | (#8273334)

N1 does not support Linux right now.

In fact, N1 does not support normal Solaris boxes right now.

It only supports Sun's blades. All of these other things will be supported in the bright, shining future, of course.

TP! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8266812)

I am also aware of one or two free TP monitors


I am cornholio!

I need TP for my bunghole!

My people.. they have no bungholes..

Read this link (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8267110)

And think about how you are wasting your life away [] diddling around with computers.

WTF? (4, Insightful)

smoon (16873) | more than 10 years ago | (#8267638)

Part 1: Rant (stay tuned for part 2)
Why debian? Don't get me wrong -- debian is great for a lot of things, but ... sheesh. Are you making a political statement or trying to support an enterprise need?

Focus on the tools you need _first_ and the OS they run on second. Getting a great OS with no tools is a lousy place to be, especially after a few months when the client has refused to pay some bills because things aren't working and you have to explain at a meeting between their CEO/CFO/VP of whatever and your CEO/VP/whatever exactly why not, and that to fix it they need to invest $X more in some other platform along with $Y to migrate.

Part 2: Some ideas
The TP monitor (e.g. CICS) is frequently done now in a database, so use begin trans, commit trans or rollback trans, and you've got transactions. At least until your database or number of users gets too big. Postgres is a good open-source database that has commercial support options and supports transactions. There are several others, sapdb I think is one. Not sure if mysql supports transactions or not. This is an area where a commercial app (DB2, Sybase, Oracle) may be a worthwile investment, especially if you get into clustering or HA hardware setups.

Many people use the J2EE framework. In open source that pretty much means jboss. Runs great on linux and you get to deploy lots of apache servers and use buzzwords like 'entity bean' and 'xml'.

What in the h*ll do you need to do schedule-wise that can't be done in anacron and some simple shell-scripting? There is a reason there aren't really any open source schedulers: cron and anacron are ubiquitous and do what they do extrememly well.

Re:WTF? (0)

Anonymous Coward | more than 10 years ago | (#8268250)

I'm telling, smoon!


Smoon said "h*ll"!

Re:WTF? (1)

Mr. Piddle (567882) | more than 10 years ago | (#8269828)

Many people use the J2EE framework. In open source that pretty much means jboss. Runs great on linux and you get to deploy lots of apache servers and use buzzwords like 'entity bean' and 'xml'.

Yes, but, everyone, please go get some real training before going all-out on J2EE. J2EE is really great, but the developers need some perspective of its complexity before it can be used effectively.

Re:WTF? (2, Informative)

jbplou (732414) | more than 10 years ago | (#8280880)

MySQL supports transactons on table types of InnoDB and BDB.

MySQL supports transactions!! (1)

gd23ka (324741) | more than 10 years ago | (#8296564)

Not sure whether mysql supports transactions or not. MySQL supports transactons on table types of InnoDB and BDB.

I know someone else already set this straight in this thread but I suppose you can't stress this simple and important fact more than enough! Moderate this as redundant, I can afford to loose some Karma over a database that has constantly kept bread on my table this and the entire last year. Why looks like next month I'm going to get another project migrating from Informix to MySQL :-)

Sad reality is multiplatformic (2, Insightful)

korpiq (8532) | more than 10 years ago | (#8267762)

IT is infrastructure for companies. It is not (arguably ever) their essential business. Their essential business is a combination of management, sales, accounting, production and assorted support procedures for the aforementioned as well as for their clients. Each stream of the gigantic process that is the company has specific tool requirements. I can not see a sustainable model wherein an IT department (outsourced or not) could keep up to its clients' necessities from any monocultural standpoint. I'd rather prepare to separate each task to a platform that best supports it, then define these separations and make my staff follow the definitions, of course redefining where need arises.

Now as for small companies that cannot afford a multitude of servers, I'd offer a single solution that best fulfills most of their needs and that I would like to keep up and polished for them myself... A debian.

UserLinux - "Debian Enterprise" (5, Informative)

Humble Legend (254888) | more than 10 years ago | (#8268037)

Bruce Perens is leading the UserLinux project with the specific goal of creating a global "co-operative" if you like, of Debian GNU/Linux service provider companies (and consultants), with a completely Debian (ie. 100% Free Software) core. Additionally, the GNOME desktop has been standardized upon specifically to simplify custom/ proprietary development on top of UserLinux. See the homepage [] . The only thing might be the release-ready (version 1.0) timing; depends on your deployment timetable of course.

Except (-1, Troll)

Gothmolly (148874) | more than 10 years ago | (#8268822)

That Perens is a flaming asshole, and while people might get a warm,fuzzy feeling from sitting around the Debian campfire, large companies (read: Banks, etc) are going IBM or native RedHat support. A grassroots movement of Debian 'service provider companies' and consultants won't take off - people will ask 'who else uses this?' In the Valley of the PHB, the Man with the largest actual company providing support wins. There may be a large amount of 'Debian guys' out there, but there's only 1 IBM.

Possible Solution (2, Informative)

jmorey (38458) | more than 10 years ago | (#8268216)

Talk to the guys at I haven't kept track of their recent developments but it seems to me they could satisfy most if not all of your requirements.

Note: I'm not fully unbiased. I have a friend that works there.

TP monitoring? (3, Funny)

Anonymous Coward | more than 10 years ago | (#8268275)

TP monitoring? I usually just keep an extra roll on the back of the toilet.

Why Not Redhat Linux Enterprise? (1, Insightful)

osewa77 (603622) | more than 10 years ago | (#8268303)


Since Debian is not supported and Redhat Linux probably is, why have you decided to standardize on Debian? It beats me!

Seun Osewa

Re:Why Not Redhat Linux Enterprise? (1)

Gojira Shipi-Taro (465802) | more than 10 years ago | (#8302112)

Maybe because there's no legitimate reason to support Redhat Enterprise Linux over any other distribution appart from kickbacks to some marketing fuck?

Linux is Linux, and if some company fucks their distro up so much that a vendor hast to bend over backwards to support it, that distro should NOT be supported.

There is NO reason why what works on one distro wouldn't work on another. No LEGITIMATE reason.

don't forget (0, Flamebait)

nutsaq (116096) | more than 10 years ago | (#8268522)

debian is a nice os, but the hardware it runs on is pure steaming shit.

if your business depends on uptime (tpm down for a day while you fix a dead HD, or replace a fan?), you need redundant hardware. most free stuff just doesn't support such niceties.

in short, prepare to grab your ankles and start talking to sun or ibm now. obviously you can use deb for various non-critical systems (web, mail, firewalls etc), but core business stuff should be on "real" iron. anything that you can't hot-swap cpus in and out of doesn't count as real. obvoiusly don't make your big iron depend on your debian systems either. that would be like putting a huge deadbolt on a styrofoam door.

Re:don't forget (1)

BoomerSooner (308737) | more than 10 years ago | (#8269964)

You can get the equivalent for less by running Linux (not necessarily Debian). For the price of "Hot-Swapping" CPU's you can have multiple redundant systems setup for fail over an maintenance work. It's all how creative you are in setting up your systems. I guess when it's your business you look for the best tools at the best price. You're exactly the type of closed minded IT elitist that my company would never hire. If you cannot think of more efficient, better priced solutions than "Buy Sun/IBM", I feel for any company trying to be profitable with you as the person making suggestions/decisions.

My .02 (5, Interesting)

abrotman (323016) | more than 10 years ago | (#8268848)

Debian is a great choice. Everyone complains about the old software, but the advantage for enterprise is the long release cycles. This is exactly what RH is shooting for with RH AS/ES. At my company we have a mix of RH and Debian. The Debian servers don't crash for no apparent reason(seems to be a kernel oops related to swapping, dumb on a www server with way more ram than it uses).

Using debian for commercial stuff isn't as easy as it should be. Many companies don't support debian and seemingly have no desire to. One of those is Oracle. Oracle can be installed on Debian, and there are tons of docs out there to do it. In the end, if you really want debian, stick to your guns until you run out of bullets.

Another option, tell these companies you're gonna buy X dollars of thier stuff, but only if they make it run on debian on your hardware. If you're willing to spend a few million on Oracle, I'm sure oracle will make it work. The same goes for IBM. I know IBM does tons of software sales, and says they support RH/Suse, but theres no reason they can't make it run on debian.

I really dont understand why companies dont support debian(please no RPM vs. DEB), in spite of the long release cycles. IMO, it makes it the perfect candidate. Once something is released as stable, it will generally stay that release for at least a year, sometimes two. Oracle could begin to certify Debian/sarge now, and when its released they would have a deployment platform for quite a while. Hell .. They could even setup thier own apt repository with Oracle specific software/patches.

Re:My .02 CDN (1)

Marillion (33728) | more than 10 years ago | (#8271568)

I would agree that long cycles is probably better for enterprise customers. Having worked with HP-UX systems before, I know first hand that Debian is downright snappy compared to HP "Official" packages. I my memory is correct, the version of Perl that installs with HP-UX 11i is Perl 4.036.

Re:My .02 (1)

afidel (530433) | more than 10 years ago | (#8301387)

Considering that only RH AS/ES and United Linux are listed as supported Oracle Linux platforms I REALLY don't think it would be a good idea to try to run a production system on Debian. Yes they will still support the DB on other flavors of Linux but if you run something other than the supported platforms then Oracle has an automatic out for any problem that they can reasonably point at the OS for.

scheduling tools (5, Informative)

cavehobbit (652751) | more than 10 years ago | (#8270270)

Scheduling is a lot more complex that I have seen anyone give credit for so far.
Add in : multiple platforms, vendors in different countries with different time zones, holidays, cultures and calendars, (try matching our Julian or Gregorian calendar to a Lunar calendar), with varying schedules, such as cyclical/hourly, daily, weekly, monthly, quarterly, annual. Matching them to accounting needs like a fiscal year that does not match the calendar year, production schedules that cross week and month boundaries, and online systems that are up or down different days of the week and things can get very crazy very fast.

I can point you to 2 companies that seem to offer the most complete solutions for multiple platform shops, other than IBM's Tivoli, which works fairly well from what I have heard:

Cybermation in Canada makes a product called ESP: duling

They have a cute little site at: t.htm l .

I was at a very large company when they swapped over from the CA7 tool to this one on their MVS systems. I was impressed with the product and the company's support. That was 8 years ago or so, so I cannot vouch for the product or the company now, but I have heard only good things about them currently.

BMC markets a product called Control-M, with all kinds of modules including an Enterprise Manager:,2831,190 52_19429,00.html

I currently use this product in an MVS/Unix/WinNT/Oracle/SAP environment. It does work. It has it's issues and shortfalls, and we have some problems with support, but we have managed to complete our schedule across all platforms every day, with only a very few exceptions in the past 3 years I have worked with it. We run in excess of 10,000 batch/background processes per day across many platforms.

In all 3 cases, Tivoli, Cybermation, BMC, licensing can be a bit pricey. But if you research the products closely, and only license what you really need as opposed to what you think you need, you can get by.

I also strongly suggest you hire an experienced scheduler to help out. This is a very undervalued and complcated specialty. Like programming, many can muddle through but few are truely good at it.


Re:scheduling tools (0)

Anonymous Coward | more than 10 years ago | (#8284058)

Another batch kind of scheduling tool would be Appworx, but I'm unsure of the manufacturer or if it runs on Linux.

Re:scheduling tools (0)

Anonymous Coward | more than 10 years ago | (#8385230)

The name they gave me is kind of funny. I think I may be a coward right now. Okay, here goes.

We are seriously evaluating moving from Ca7 to ESP. However, we cannot find much information out there that wasn't giftwrapped from Cybermation. Moving to event based scheduling would be a significant change in scheduling logic and exception handling. I've already converted from an event based scheduler to Control-m. Never converted the opposite direction.

Were you part of your earlier companies conversion efforts? How large was the company and it's streams? Were they cross platform? How painful was the experience? Do you have any advise for something of this nature?

I have heard that ESP stores the passwords for its distributed clients in files. I can't verify this but if the conversion goes ahead my team may have to convert again over to ESP to bring us to a single view. If this is true the distributed side of the house would have concerns.

Thank you for the compliment to scheduling. Its appreciated.


Talk to IBM sales (2, Insightful)

metamatic (202216) | more than 10 years ago | (#8272365)

As far as IBM is concerned, money talks. If you are planning a 100,000 seat Debian deployment and want IBM tools, contact IBM sales and tell them. If enough people ask, maybe Debian will become a supported platform.

Plenty of us inside IBM would like to see some free Linux distributions supported, but the company makes its decisions based on commercial pressures, not ideology, and right now not enough people want to run their enterprise on Debian, Gentoo or any other free (beer) Linux.

We use IBM & Debian (3, Informative)

Howard Beale (92386) | more than 10 years ago | (#8274685)

And even though Debian is not an officially supported distribution, IBM *has* supported us. Mind you, we're not a real big shop (xSeries 330 with a 1 TB EXP300 array), but they've done a fantastic job and won our support.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Create a Slashdot Account