Slashdot Mirror

What competitor?

Redhat
Suse Mandrake
To name a few...

If I remember correctly, those are all business who sell's Linux based operating system.
Direct competitors to Microsoft I would think...

How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!

You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!

Join the campaign for more cute open source babes today!

Of all of these, I like OpenACS the best, mostly because of its developer community. There are a lot of great people involved, and there's a high signal to noise ratio on the developer forums. Even though OpenACS probably has the least of what you're looking for, it might be the easiest to develop. OpenACS runs on top of Postgres or Oracle, and is written in Tcl.

Redhat CCM is basically a Java rewrite of the original OpenACS. Its CMS modules are supposedly more mature. It runs on a Redhat version of Postgres, and I think Oracle too.

Zope is a whole lotta product, and probably has most of what you're looking for. However, I find it kind of murky, difficult to figure out. YMMV.

These three are the most promising in terms of developer community. This is a bigger undertaking than it might seem at the outset. You'll need all the help you can get, and getting involved with these communities will spare you from trying to reinvent the wheel.

Of course, I'd love to have you guys use and extend the OpenACS toolkit, and share your efforts with the community!

It been a few years, and I still think this is the funniest story I've ever read. To this day, I cannot read this, or even think about it, without laughing out loud in a really embarrassing way.

There are plenty of companies which specialize in support for Linux and Open Source.

I mean really, you don't need to pay millions of dollars for support, though it is more difficult to find 24x7x365 support with 4 hour turnaround when you're talking $10,000/year instead of $250,000.

Then again, does your company really *need* that level of support? I would venture to say that they probably don't. If you build redundancy into your systems, you should be able to get by in most cases, albeit under heavier load. For 24x7x365 support, expect to spend $$$$.

IIRC, many companies provide Linux support agreements. The submitter should look into those.


RedHat is probably an example.

No, I don't work for them, but Linuxcare has a professional looking website using the CEO-lingo that might comfort the big-wigs you need to convince. There are other companies that support Free Software too, check out Red Hat's Support Services. A site called OpenEnterprise looks to have a ton of resources on exactly what you're asking for.

Also, take a look at IT Management's special report on Linux. It offers a lot of ammo to you in making a presentation. You can point to the other heavy-hitters that are using Free solutions and have concrete examples of success.

The same site even has an article entitled Selling the 'Suits' on your IT project which looks to have some good advice for you.

I'm a little surprised this hasn't come up yet...

If you're looking for "enterprise" level support (God I hate that word!), Red Hat offers exactly what you're looking for, from what it looks like. Maybe you should give Red Hat a call and get one of their sales people to pimp themselves to your boss? :)

that only open source software can provide on a UNIX platform (VNC, OpenSSH, etc..)

VNC and OpenSSH are available for windows so they might not be convincing. Try using ROI and TCO as persuaders.

With the dot-com bust giving Transmeta a hard time, an approval by Microsoft could be just what they need to get back on their feet and out of bankruptcy.

Maybe this will be a lesson learned for the GNU/Linux community as well, to support the companies that use open source and contribute back to the movement. Everyone's all about freedom, but nobody seems to want to pay the price for it. Apparently Transmeta has seen this and is moving on to greener and more friendly pastures. Good for them I say, and I'm looking forward to the product.

Think about that the next time you Bittorrrent the latest release of Redhat instead of purchasing it. What would you do if they decided to switch over to Microsoft? You'd all be screwed then.

I dont know if RedHat Linux supports Mt Rainier, but here you will find Mount Rainier supporting (some of) RedHat!

KDE is not everyone. They are a company that has benifited extensively from GNU tools and the philosophy behind them. It's not much to ask them and folks like Red Hat to smile at the hand that feeds them. Stallman is intersted in forming and enlarging a community. That won't happen if people grab the tools but forget why they exist. He probably does not care how you are I say things, so long as we have gotten the word. KDE and others are in the best possition to understand and spread that word.

From the description, RMS enjoyed and appreciated the contributions the KDE folks are making and no one got their feathers ruffled.

http://people.redhat.com/mingo/exec-shield/ANNOUNC E-exec-shield

___________________

[Announcement] "Exec Shield", new Linux security feature

We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:

http://redhat.com/~mingo/exec-shield/

The exec-shield feature provides protection against stack, buffer or
function pointer overflows, and against other types of exploits that rely
on overwriting data structures and/or putting code into those structures.
The patch also makes it harder to pass in and execute the so-called
'shell-code' of exploits. The patch works transparently, ie. no
application recompilation is necessary.

Background:
-----------

It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.

Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.

This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.

Implementation:
---------------

The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.

the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.

Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:

http://somehost/buggy.app?realyloooooooooooooooooo oong.123489719875

then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.

With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:

$ ./cat-lowaddr /proc/self/maps
00101000-00116000 r-xp 00000000 03:01 319365 /lib/ld-2.3.2.so
00116000-00117000 rw-p 00014000 03:01 319365 /lib/ld-2.3.2.so
00117000-0024a000 r-xp 00000000 03:01 319439 /lib/libc-2.3.2.so
0024a000-0024e000 rw-p 00132000

http://people.redhat.com/mingo/exec-shield/ANNOUNC E-exec-shield
_____________________________________________

[Announcement] "Exec Shield", new Linux security feature

We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:

http://redhat.com/~mingo/exec-shield/

The exec-shield feature provides protection against stack, buffer or
function pointer overflows, and against other types of exploits that rely
on overwriting data structures and/or putting code into those structures.
The patch also makes it harder to pass in and execute the so-called
'shell-code' of exploits. The patch works transparently, ie. no
application recompilation is necessary.

Background:
-----------

It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.

Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.

This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.

Implementation:
---------------

The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.

the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.

Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:

http://somehost/buggy.app?realyloooooooooooooooooo oong.123489719875

then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.

With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:

$ ./cat-lowaddr /proc/self/maps
00101000-00116000 r-xp 00000000 03:01 319365 /lib/ld-2.3.2.so
00116000-00117000 rw-p 00014000 03:01 319365 /lib/ld-2.3.2.so
00117000-0024a000 r-xp 00000000 03:01 319439 /lib/libc-2.3.2.so
0024a000-00

I personally ordered two Opteron servers this week. I plan on building an e-mail server and K12LTSP server using modified Red Hat Linux. My findings of success/failure when I figure out AMD64 Linux quirks will be posted to AMDMB.com in the coming weeks. (Also check out our Athlon Linux forum.)

From the AMD64-list discussion so far, there are only a few details:

* Kernel and all applications 64-bit compiled. This includes support for the larger memory address space and 16 registers. (SPEED!)
* AMD64 Linux *can* run 32-bit applications, unfortunately you would need 32-bit shared libraries that were not included in this technology preview. They said that they will be included in a possible future shipping distribution. I personally will try to research how to find/build these 32-bit shared libraries for myself, although I suspect it will show up on amd64-list soon enough.
* Existing 32-bit closed source programs like Macromedia Flash plugin 6.0 for Linux may work with 32-bit shared libraries, but not while running within 64-bit compiled Mozilla. You would need 32-bit compiled Mozilla. Bummer.

I personally ordered two Opteron servers this week. I plan on building an e-mail server and K12LTSP server using modified Red Hat Linux. My findings of success/failure when I figure out AMD64 Linux quirks will be posted to AMDMB.com in the coming weeks. (Also check out our Athlon Linux forum.)

From the AMD64-list discussion so far, there are only a few details:

* Kernel and all applications 64-bit compiled. This includes support for the larger memory address space and 16 registers. (SPEED!)
* AMD64 Linux *can* run 32-bit applications, unfortunately you would need 32-bit shared libraries that were not included in this technology preview. They said that they will be included in a possible future shipping distribution. I personally will try to research how to find/build these 32-bit shared libraries for myself, although I suspect it will show up on amd64-list soon enough.
* Existing 32-bit closed source programs like Macromedia Flash plugin 6.0 for Linux may work with 32-bit shared libraries, but not while running within 64-bit compiled Mozilla. You would need 32-bit compiled Mozilla. Bummer.

Yeah, until a common library (Let's call it zlib, or if you prefer openssl) turns out to have a buffer overflow or other security bug in it which has been there for years (Let's say that happens today, or has several vulnerabilities patched a couple of times in a single month), and you realize that it happens to be included 45 different times on your system. Or even better yet, each one has some slightly different tweeks applied to them so you can't just replace them!

Shared libraries aren't just for saving RAM and harddisk space.

Yeah, until a common library (Let's call it zlib, or if you prefer openssl) turns out to have a buffer overflow or other security bug in it which has been there for years (Let's say that happens today, or has several vulnerabilities patched a couple of times in a single month), and you realize that it happens to be included 45 different times on your system. Or even better yet, each one has some slightly different tweeks applied to them so you can't just replace them!

Shared libraries aren't just for saving RAM and harddisk space.

Yeah, until a common library (Let's call it zlib, or if you prefer openssl) turns out to have a buffer overflow or other security bug in it which has been there for years (Let's say that happens today, or has several vulnerabilities patched a couple of times in a single month), and you realize that it happens to be included 45 different times on your system. Or even better yet, each one has some slightly different tweeks applied to them so you can't just replace them!

Shared libraries aren't just for saving RAM and harddisk space.

ooops, messed up my href.
RHN

" The way things are structured today, from a licensing perspective, in the Linux world nobody will ever commercialize Linux the way the Sun commercialized FreeBSD."

Forgetting RedHat, Mr. Balmer?

You confuse objprelink with the real prelink.

How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!

You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!

Join the campaign for more cute open source babes today!

There's also Cygwin, which is a sort of mini-distro for Windows complete with XFree and a few basic window managers (fwm and OpenBox among them). Great package manager, lots of mirrors and great quality overall. It sometimes beats booting into Debian =)

Note that you'll want to run it in NT4 or better (IMO), but it's a very nice introduction to UNIX-like environments, especially the X server support (since bash is not very flashy). It's actually quite neat to have a full screen X session running on top of the Windows desktop.

It also ships with the GNU toolchain so you can even write your own little aps (console, GTK or plain X).

How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!

You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!

Join the campaign for more cute open source babes today!

How can BSD be dying when it has a mascot like this?! Linux needs to get its act together if it's going to compete with the kind of hot chicks and gorgeous babes that BSD has to offer!

You just can't take Linux seriously when its fronted by losers like these. You Linux groupies need to find some sexy girls like her! I mean just look at this girl! Doesn't she make you hard? I know this little hottie floats my boat! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little cock teaser. Even this old bearded Unix guru is apparently unable to take his eyes off her!

Join the campaign for more cute open source babes today!

The two offerings are not comparable. The MS offering gives you software, the Linux offering gives you support.

If you were to actually be stupid enough to do this, the first time you had a problem with your MS setup you would be thrown to the wolves, otherwise known as per-incident support and you would land there without a support budget.

For Win 2003 standard the support page is available here and in short it's $245 per incident and $1225 for a 5 pack.

The problem with buying that 5 pack of incidents is that it's only good for win2k3 incidents. Unlike the RH support which covers many products, each prepaid pack is only good for the covered product.

You get to have 48 incidents over 6 years (assuming prices do not change) or 8 incidents per year. RH does not set incident limits in its standard support contracts.

If only 8 things go wrong per year in a 6 server MS shop in both server OS and server apps, you're having a very good year. To expect to have 6 very good years in a row is not very probable.

The RH offering costs you $600 per year but each year you get updated to the then current major release. Since MS updates their OS about every 2 years, that's $6k of software cost that hasn't been accounted for to keep things even and that drops you down on the MS end to 4 incidents per year across the OS and the relevant enterprise applications you'll be running. Good luck on having two major OS upgrades over 6 servers and only having 4 incidents per year.

Finally, before anybody starts whining about the free support options or MS' $99 online option they aren't comparable as RH is offering 4 hour support response time, not 24 hour and Linux forums exist with exactly the same price as the MS forums, free.

Actually, the more boxes you put into the equasion, the cheaper Windows gets, because the big cost is the CALs.

150 Users, 6 Servers:

Windows 2003: $9600 covers all 6 servers and all the users for the entire six year support cycle.

RedHat ES: $600 per year per server x 6 years -> $21,600

In otherwords, Linux can be a shaft.

Have you tried automake? (autotut, autobook)

Dear reader the GNOME armageddon has started,

First of all I want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it.

Belive me it took me a couple of days writing this text in a foreign language.

Even if you don't care at all for GNOME, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

On the following lines i'm trying to give you a little insight of the GNOME [gnome.org] community. the things that are going on in the back, the information that could be worth talking and thinking about.

Many of us like the GNOME desktop and some of us were following it since the beginning. GNOME is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of *NIX, only to name some of its advantages.

Unfortunately these advantages changed with the recently new released version of GNOME. The core development team somehow got the idea of targeting GNOME to a complete different direction of users, the so called corporate desktop user.

In other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting GNOME on their computers.

Having this new target in mind, the core development team mostly under contract by companies like RedHat, [redhat.com] Ximian [ximian.com] and Sun [sun.com] decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. So far the idea of a clean easy to use desktop is honourable.

Some of the new ideas, features and implementations such as gconf, [gnome.org] an evil Windows Registry-like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that GNOME leads and the attitude of the core development team made a lot of users really unhappy. These are only a couple of examples and the list can easily be expanded but for now this is enough. Now let me try to get deeper into these aspects.

You may imagine that users got really frustrated, [osnews.com] because their beloved GNOME desktop matured into something they didn't want. During the time, the frustration of a not less amount of people increased. more, [gnome.org] more [gnome.org] and more [gnome.org] emails arrived on the GNOME mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

But the core development team of GNOME don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. The reply they give is mostly the same -- users should either go and 'file a bug' at BugZilla [gnome.org] or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback [gnome.org] isn't appreciated.

If you gonna think about this for a minute then things gonna harden tha

Dear reader the GNOME armageddon has started,

First of all I want to clarify that this text was meant to be a source of information otherwise i wouldn't have spent so much time into writing it.

Belive me it took me a couple of days writing this text in a foreign language.

Even if you don't care at all for GNOME, you may find some interesting information within this text that you like to read. please try to understand my points even if it's hard sometimes, otherwise you wake up one day and feel the need to switch to a different operating system.

On the following lines i'm trying to give you a little insight of the GNOME community. the things that are going on in the back, the information that could be worth talking and thinking about.

Many of us like the GNOME desktop and some of us were following it since the beginning. GNOME is a promising project because it's mostly written in C, easy to use, configurable and therefore fits perfectly into the philosophy of *NIX, only to name some of its advantages.

Unfortunately these advantages changed with the recently new released version of GNOME. The core development team somehow got the idea of targeting GNOME to a complete different direction of users, the so called corporate desktop user.

In other words they're targeting people that aren't familiar or experienced with desktop environments. usually business oriented people who are willing to pay money for getting GNOME on their computers.

Having this new target in mind, the core development team mostly under contract by companies like RedHat, Ximian and Sun decided to simplify the desktop as much as even possible by removing all its flexibility in favor of an easy clean simple interface to not confuse their new possible customers. So far the idea of a clean easy to use desktop is honourable.

Some of the new ideas, features and implementations such as gconf, an evil Windows Registry-like system, new ordering of buttons and dialogs, the removal of 90%-95% of all visible preferences from the control center and applications, the new direction that GNOME leads and the attitude of the core development team made a lot of users really unhappy. These are only a couple of examples and the list can easily be expanded but for now this is enough. Now let me try to get deeper into these aspects.

You may imagine that users got really frustrated, because their beloved GNOME desktop matured into something they didn't want. During the time, the frustration of a not less amount of people increased. more, more and more emails arrived on the GNOME mailinglists where users tried to explain their concerns, frustrations and the leading target of GNOME.

But the core development team of GNOME don't give a damn about what their users are thinking or wanting and most of the time they come up with their standard purl. The reply they give is mostly the same -- users should either go and 'file a bug' at BugZilla or the user mails are being turned so far that at the end they sound like being trolls or the user feedback is simply not wanted. whatever happens the answers aren't really satisfying for the user. even constructive feedback isn't appreciated.

If you gonna think about this for a minute then things gonna harden that they are directing into the commercial area. The core development team actually don't care for the complaining home user -- it's more

If Novell can bring a good, stable NDS implementation to Linux then Linux will gain a LOT in the Enterprise.


That happened three years ago. They've also ported it to Windows, Solaris, and AIX.

Get your download on and try it out.

The SCO® Group (SCO)(Nasdaq: SCOX), a leading provider of Linux and UNIX business software solutions, ...

A thousand dollars for a linux install, eh? These SCO people must know something I don't. Seriously, can anyone tell me what would justify paying that?

But, Notes and Domino have continued to be the most important under IBM's management.

And Linux on zSeries is just RedHat (or SuSE or Turbolinux) build using a zSeries-patched kernel and sold and supported by the Linux vendor of your choice.

"How much does Linux cost?"

Somewhere between $39.95 and $149.95.

"OTOH WinCE developers are paid nothing for fixes to a product that costs real money."

As opposed to the fake money Redhat charges.

"M$ is probably correct in assuming that developers will be motivated to produce fixes/additions to enhance the functionality of their own products."

Who is M$? I thought we were talking about Microsoft here.

"And if Microsoft continues to exploit their leverage like this they will alienate their developer base."

Alienate? You mean like how all the open source zealots are alienating developers by demanding they give away their work for free? At least Microsoft doesn't do that.

"If I were a device manufacturer I certainly wouldn't develop any new features for WinCE; I would be working for M$ for free."

Again, just like you work for Redhat for free, just like you work for other companies that take free software projects and resell them, just like you work for other companies that provide support for free software projects for a fee.

This isn't a valid complaint... you've been doing this for years, and you have been perfectly content to let people take advantage of you.

Now you want to come here and claim Microsoft is going to take advantage of you?

And you wonder why the development world considers open source people a bunch of whiners? Sheesh, look in the mirror.

Collaboration is a good thing. It's the foundation of things like the Free Software movement, and Open Source movement. It's how performers make good music.

Arguably, it also produces a lot of trash, but hey, there's a market for that, too.

The interesting thing here is that O'Reilly is taking this up with Gillmor. Not everyone can get published by O'Reilly, so what's a regular guy to do?

Use Lulu.com, a new site founded by Bob Young, formerly of RedHat. You register as an author, and your collaborators register as an author, and you can all submit chapters to each other's books for collaboration. Then you can set price for online, print, or cd distribution, collecting an 80% royalty. No other publishing deal I know of sets an 80% royalty to the author.

Or choose no royalty and set the price for online distribution to free. Books can be published under any license you like, just place the copyright page with the license you like in the book when you upload it.

B) Where's your service contract? A big point among low-end Sun customers (like the service, not the price).

D) Lots of tasks commonly run on Unix are decidedly low-end and commodity. Mail routing, DNS, HTTP, etc. IMO, you'd be stupid to pay Sun big bucks to run this stuff.

Perhaps this "leak" is to take attention away from new releases of excellent servers: OpenBSD 3.3, RedHat 9 (even w/4 business hour response time), and Mandrake 9.1.

But I can guess at two reasons why it comes just now:

Perhaps this "leak" is to take attention away from new releases of excellent servers: OpenBSD 3.3, RedHat 9 (even w/4 business hour response time), and Mandrake 9.1.

Or perhaps it is to drum up sympathy in congress for new legislation which could be used to mandate DRM in the U.S. This would hamstring the U.S. IT sector and many public institutions by taking money out of already tight budgets and sending it to Redmond in the form of forced purchases of new hardware and software.

Your post implys, IMHO correctly, that no matter the steps taken to protect software against piracy, there will be piracy. However, there will emerge in the end a need to by software from a vendor in order to get support. Hmmmmm...

Seems to me there's a few companies out there who do something very much like that. Seems we have the answer for Microsoft, don't we?

Soko

Ah, even if RedHat's FTP site won't allow more anonymous users, you can still hit their http version of the ftp site to get the MD5SUM to verify any of the ISO files you get from a mirror site. Mind you, this site is slow (took 5+ minutes to connect and get this 618 byte file, but it did go through eventually):

http://ftp.redhat.com/pub/redhat/linux/9/en/iso/i3 86/MD5SUM

Here's what you have to do to distribute your own CDs of RedHat Linux:

Step One: Remove the "redhat-logos" package. (If you want your installer to work, you'll probably have to remove the package file and the references to it in the kickstart package list.)

Step Two: Think of a name. It can be anything, as long as it's not "RedHat Linux."

That's pretty much it. The code is GPLed; their name and their art assets are not. Anyone who can't be bothered to do the two steps above, I don't really have much sympathy for when RedHat's lawyers engage the bitchslap machine.

Incidentally, this is all well documented on redhat.com. All you had to do was search for 'redistribution' on their website.

Is this the same as the vuln reported in Red Hat RHSA-2003-095? The links in the article to the vuln info are down right now.

If it is, RH has had this licked since April Fool's. At least someone was being productive that day.

See this bug.

The source code for the tip as well as the latest stable release is of the enterprise applications are available at http://ccm.redhat.com/. So, you can download it and give it a spin. The tip really is the tip and has all of the features but may not be as stable as you might like. It runs on both oracle and pg.

It's a known bug in XFree86 4.3 when using DVI. Switch to your monitor's VGA port, install nVidia's current drivers, switch back to DVI. Or do a textmode install. I'm using RH9 with nVidia's drivers on my ViewSonic VG191b w/DVI now.

It is likely that other distributions using XFree 4.3 will have the same problem. I didn't have this problem with Red Hat 8 (XFree 4.2).

Be sure to pick up the "missing" RPMs on freshrpms.net when you're done.

I do wish nVidia would update their platform drivers. I had to build the nvnet driver for my nForce2 board the hard way rather than use their RPM. I'm using ALSA (thanks freshrpms!) for audio.

ArsDigita never made "Open"ACS. ArsDigita created ACS as an open source toolkit supporting the Oracle database. The OpenACS project came about when ArsDigita decided to make their Java project which is what has become Redhat CCM.

Red Hat purchased all of ArsDigita's assets and this project belongs entirely to them now.

OpenACS currently is a TCL/AOLServer based project that supports Oracle and PostgreSQL.

RedHat has made what looks like an effort to reduce confusion by renaming the "Red Hat Database" project as "PostgreSQL - Red Hat Edition" http://sources.redhat.com/rhdb/

Linux kernel 2.4.20, GCC 3.2.2, GNU libc 2.3 (with NPTL)

I thought NPTL was designed around the Linux 2.5 kernel. Did they backport futexes and stuff required for NPTL to 2.4.x? Also, how can this be stable? They are still finding bugs in NPTL to this day.
Is LinuxThreads still used by default for applications and NPTL only if you specifically set it up to used that shared lib?
This is not a flame - I'm just wondering what's going on.

The source code for the tip as well as the latest stable release is of the enterprise applications are available at http://ccm.redhat.com/.