I'm sorry but I think this grossly misses several points and undermines the appropriate difference between threads and processes.
One way to think of threads is as a solution to bloated processes. In operating systems like Solaris, which are designed to scale to 32 or 64 (or more) processors, the number of locks in the kernel is enormous. As a result, context switches and process creation time tend to be higher. In gross terms, you pay for the concurrency at high numbers of processors with poor performance at lower numbers of processors. This is not necessarily bad (especially if you plan to use 16 or more processors at some point) but it is just the way things are.
Linux, on the other hand, penalizes scalability for large numbers of processors in order to get much better performance with smaller numbers of processors. Linux does this because Linus doesn't believe that 16+ processor machines are common or sensical and that the kernel should be optimized for common (and sensical) cases.
Why do I mention all of this? Because Linux process creation times are slightly faster than Solaris thread creation times. Anyone who fetishizes multi-threading versus multi-processing doesn't really understand the difference between the two and when it really matters.
Processes are contexts of execution. Threads are contexts of execution that may share a memory space with other contexts of execution. These are fundamentally different things in some operating systems. In Linux, a thread is just a process that shares a memory space with another process. This is because processes are *fast* to create and switch to in Linux (optimized for the common case, remember?).
Anyway, I don't mean to bash maraist at all, just to point out a common set of misconceptions about these things. When considering these architectures, each database system must try to optimize across all of the operating systems they plan to be deployed on (just like the apache project, which i think was an excellent analogy).
I should say at the outset: I've used both Postgres and MySQL on production projects and like both for very different reasons. But here's the thing (and this is a common problem with technology product evaluations): these products have very different design goals and aren't really that comparable.
I'm not saying the standard "MySQL's not a database because it doesn't support transactions and databases have to. ACID!" (although I'm sympathetic to that point of view, I don't think individual words like "database" are worth fighting over--If MySQL wants to call itself a database, fine). What I am saying is that Postgres was designed to be a full-fledged SQL92-compliant database with transactions and triggers and foreign keys and the whole lot. MySQL was designed to be a SQL-based front-end to a very fast database file format. These products are not the same and comparing them without agknowledging that seems foolish.
I've been very pleased by the speed improvements in Postgres recently (partisan testing aside, Postgres 7 really is much faster). I've also been impressed by feature additions in MySQL (although it still isn't close to what you would expect to get if you're coming from the Oracle or DB2 world). But both remain inherently died to their design goals. This isn't a bad thing, at all, because different projects need different products with different design goals.
I compare this to the (often senseless) comparisons of NetBSD, OpenBSD and FreeBSD. One is designed for portability, another for security (features be damned!) and the last for performance, features and multi-processing under (primarily) intel. Although they come from a common code base, they have obviously diverged in design goals. Instead of bashing one product or another (all of the *BSD's and the two databases discussed have *major* problems that are bashable) use the one that seems most appropriate to your needs.
I'll admit it: I'm still a twofish fan. I look at the number of rounds required to make rijndael reasonably secure and compare that to twofish and i don't feel happy. This is not to say that I don't think that Rijndael is secure now--it clearly is. This is also not to say that I think there's some good way to reliably determine the likely future security of uncracked algorithms--I think there is not. Nevertheless, we can guess about future security based on things like complexity (where twofish scores poorly) and number of rounds required for security (where twofish scores extremely well and rijndael does not).
There were two lurking decision factors in the AES that concern me:
1) patents. it has not been made clear how much the hitachi claimed patent affected the outcome.
2) embedded devices. i believe that the decision was weighted in favor of current embedded memory and computational power, which doesn't make any sense. Embedded applications will be more powerful by the time anyone actually implements this stuff and I'd much rather have something that is excellent on real computers and fine on smart cards, but that doesn't seem to be what we've ended up with.
Anyway, I'm glad to see the process was open and all kvetching aside, Rijndael is a *huge* improvement over DES or even DESX or tripleDES. The authors of all algorithms deserve congratulations.
what i find hillarious is that the translation still only really makes sense if you already speak some German. not much, mind you. I have two semesters of college german 8 years ago, but it is necessary.
Two funny things: the first is verb order. German puts verbs at the end of phrases and sentences. eg: "he thinking about other things walked" or "after i working had finished tired i was". Given that this is an incredibly standard sentence pattern in German, you'd think an automatic translation engine that knew something about grammar and parts of speech could move stuff around (English is one of the most word-order sensitive languages in the world due mostly to our lack of other correlational clues such as gender and mood and our relatively weak cojugation of verbs. english-speakers *need* good sentence order to understand things in a way that spanish or arabic speakers are more flexible about).
second thing: simple words missing. 'Jetzt' means now. i knew this after a few weeks of german education. this should not be hard to translate. 'guten taste' is actually 'good taste'. my point here is that the translation engine seems to barf on simple words for no apparent reason. wired mag had an excellent article a while ago on machine translation (at http://www.wired.com/wired/archive/8.05/translatio n.html) that shows how challenging this stuff is.
i'm not really complaining because i find the translation a wonderful bridge between two semesters of german and being able to read the whole article. i can actually *read* and *understand* the article in the translation. i don't believe that someone with no german could do that very well yet. but this stuff is getting there.
In the long run, we all know that what will count is OS support. IBM has a strong, stated linux strategy, but we'll see where it goes.
Don't get me wrong, I am one of the few who actually like AIX. I think it's a mature, useful operating system with some really cool characteristics (fairly integrated hw support and debugging, excellent logical volume manager (better than veritas, imho)). nevertheless, it remains to be be seen whether IBM can actually bring Linux to their whole server platform (including these bad boys).
(There have been instruction set changes in the IBM processor line in the past, particularly between the POWER, POWER2 and POWER3 architectures, so I'm interested to see what the differences in this instruction set are...).
One other thing i thought of that hasn't really been discussed (probably because a disgusting majority of slashdotters are male and are not very gender-aware): are on-call policies gender biased?
women are more likely to have family responsibilities (whether children or elderly, we rely, as a society, on women to take care of everyone). as a result, it may be more difficult for them to take care of on-call duties than it is for men.
does anyone work anywhere where on-call policies are sensitive to these sorts of considerations (not gender, specifically, obviously, but different amounts of time that different people spend on caring for family members)?
I work for a medium-sized regional ISP. We have three call rotations (plus one for senior management): systems, networking and customer service (we don't operate a 24x7 call center). The call rotates through departments of 4-5 people, so everyone is on-call every 4-5 weeks.
We compensate people by paying them an extra day (8 hours) for each week on call at their current rate (everyone is salaried, so there's no easy way to pay them a multiple of current hourly rate.
There's not really differential compensation for what people do when they're on call but if it's really busy most managers give people comp time.
So Germany and France are both very close to either strongly preferring or requiring open source software for certain kinds of government implementations (or so we've heard). OTOH, i've read that most US federal agencies are strongly perferring COTS (Commercial Off The Shelf) software solutions with a minimum amount of integration and custom code written.
This is the challenge that open source actually solves fairly well and fairly directly: COTS products are preferred because government agencies (and most private organizations as well) have a proven inability to develop software (they just write crappy code, manage their projects poorly and usually never finish). Given this environment, they'd like to 'just buy' everything (My slogan is that although you can do almost anything, you can't "just" do anything--integration is tough and no amount of management ignoring it will change that).
On the other hand, we read stories like this (and this one if funny, but hardly unique) about governments getting srewed by the commercial software vendors they use.
Open source splits this right down the middle--you get competent people to develop your products but you get access to the source to make changes if you want. cool, eh? government agencies who are nervous about this kind of thing can take a middle ground of establishing reliance on open protocols and requiring commercial vendors to support them.
I think anyone who has followed the development of the samba project over the past few years, even at a distance, can understand this fork. samba, as a project, is necessarily somewhat schizophrenic. On the one hand, the primary reason is to "emulate" file and print services provided by the microsoft platform. On the other hand, i think that the developers would like to provide an independently valuable server platform.
But samba, as a project, has not quickly been able to adapt new funcitonality provided by microsoft. encrypted passwords and PDC functionality are good example.
People in the open-source community are rightfully jittery about forks, but I think that this one could make sense. On the one hand, we get the main samba project persuing the goal of just having a great file sharing server platform. On the other hand, we have a lighter-weight project with the specific goal of just acheiving W2K full interoperability. I think this could be cool.
For a long time digital (and now compaq) have claimed that their optimizing compiler for the alpha was dramatically better than gcc. Does anyone know if this is still the case?
I know of several large alpha cluster installations (including the cplant at sandia national labs with over 1300 alpha processors!--http://www.cs.sandia.gov/cplant/), but it's never been clear that alphas really hit the price/performance curve for *integer* performance. Outside of scientific computing, floating point performance just doesn't matter that much. What matters is integer throughput and my recollection is that when considering SpecINT/$, Intel and related boxes are just cheaper.
Finally, there's the issue of datedness and market timeliness. Alpha has been around for forever and has just not really taken off in any big way, as far as I can tell. With W2K and NT dropping alpha support and no intel-killing performance on the horizon (unless wildfire is everything they crack it up to be), it seems unlikely that it will storm the market. alpha is the past. transmeta is the future ( I *know* they're aimed at completely different markets and have different design goals, but buzz is buzz and there's only so much of it to go around for processors. i don't think alpha will get any more.
Let me first say that, in general, I welcome this change to CERT policies. CERT announcements have become increasingly less relevant as the bugtraq list has grown and as the SecurityFocus team has added better tools for tracking and researching vulnerabilities. One interpretation of this change is that it represents a desperate cry for relevance by the CERT folx.
Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.
An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?
Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).
The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.
In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).
Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.
It's simple: Redhat (as several other distributions are now doing) is shipping a different compiler for compiling kernels than for general compilation.
You need to edit the kernel Makefile and add the line CC=kgcc (making sure that kgcc is installed on your system). kernel compilations will then proceed without problems.
Although this is surprising to many users, it's actually a good idea. The linux kernel stresses a compiler in ways that a regular program (even something like all of gnome) just can't do. Kernel compilation demands correctness of inlined functions, or preprocessor command parsing, of lock orders. Basically, the kernel uses C as a convenient macro language for assembly much of the time. The compiler's job is to faithfully translate.
Given all of that, the compiler that you want for general purpose compilation is not necessarily the compiler that compiles the kernel best. The kernel and compilers co-evolve. If you follow either the linux-kernel list or any of the gcc or libc lists, you will see that when bugs turn up with kernel compilation, it is as often the case that there is a libc or a gcc bug as a kernel bug. These bugs frequently only turn up in the context of a kernel compile (because who the hell else would do something like that?!?)
Finally, on the subject of the redhat release: RedHat did some dubious things (calling their gcc gcc 2.96 when 2.96 just doesn't exist, thereby forcing the gcc project to renumber their release to 2.97 just to catch any RedHat bugs, eg.). However, I'm steadily impressed by Redhat as a distro (flame me if you want, I don't care). Redhat is a commercial distribution but they release *all* the software they develop as gpl open source (and have set the tone among other distributors to do the same), and have struck a good balance between novelty and stability.
Anyway, that's how to solve your kernel compiling problem (among lots of other stuff).
Point well-made. However, if we want to get really pedantic, the system OS/390 is either an operating system or a platform, and VM is a meta-operating system (or operating sytem) that runs on system OS/390 and Linux runs under VM.:-) Gosh, these IBM folx are strange, but they do good stuff sometimes.
This is not actually that surprising. IBM has a stated goal of making linux run on every piece of hardware and every platform they sell, from the top of the line (OS390) to the bottom (intel-based netfinity line, I guess).
So there are two things going on here: 1) IBM has their own version of Unix that's quite good but not doing very well in the marketplace. 2) IBM has decided that Linux is the way to unseat Sun's dominance of the midrange server market.
Given those two facts, supporting yet a different version of Unix designed primarily for the Itanium platform (regardless of what they say about also running on the Power chip) doesn't make any sense. Even IBM has limited resources.
The web site has links to previous projects to give you some ideas about the kind of work that some of the teams have done, but overall I will say that the work is of remarkably high quality. This is a school-year-long event, so many of the projects will need to be shortened for semester-long use. They may also need to be made more simple.
As a side note, I should mention that although all of the projects can benefit from supercomputer time, the Challenge is over 10 years old as a program now. As a result, most of the projects run find on mid-range desktops (but are, neverthless, computationally intensive tasks).
This doesn't really address the issue. I know that I'm harping about this LVM stuff, but I've mentioned it a couple of times wrt to redhat and seem to have been misunderstood both times.
Here's the deal: RedHat should ship an operating system with and LVM-aware installer and LVM-tools that can create partitions across disks and resize partitions and filesystems without a reboot. It should do this in the default install (while allowing people to get out of it if they want fdisk-style partitioning).
Logical Volume Management is pretty much the holy grail of filesystem management (and anyone who's used AIX, HPUX or the veritas tools on solaris will agree).
I just want to make it clear that shipping a 2.4pre kernel on the 2nd CD with logical volume patches just doesn't cut it. Suse started shipping with the LVM and tools two minor revs ago now.
I haven't installed it yet, but it looks as thought the Logical Volume Manager tools still aren't packaged with the distro. This concerns me. This is among several concerns I have about RedHat's future directions. I've always liked redhat (since the Mother's Day release back in the day) and especially have appreciated their attempt to balance the new and fancy with stability and security.
But recently they've been failing on both fronts. Suse seems to be taking the lead on new features (with their support of X drivers, and shipping LVM and reiserfs), and Redhat has slipped on the security front. Redhat took two weeks (two weeks!) to issue patches the the last round of security problems affecting the 2.2.14 kernel. Not the 24-hour turnaround I've come to expect.
I suspect the distro will be good in other respects, though.
I love the palm. I've had a III for ages and really appreciate what it does well (and am fairly irked by the few things it doesn't do well).
But this connectivity model is for the birds. The recurring costs are high, the PQA infrastructure is not an open standard (as far as I can tell) and it's too easy to go over the limit. The model of the VII just doesn't work for me (I like the design and size of the V better anyway).
What we need is something the size and weight of teh V with color with full net access for $15 / month (how much data could you really transport with that damned stylus). The US would really do well to get off our collective butts, scrap our analog cell phone network, finish building some of the digital networks, and then allow them to be used for packet-switched data.
The point that the article seems to leave out, though, is that mediocre (or almost-free) licenses (like Sun's Community Source License, just to pick on one) are even worse for the community.
If there is a totally non-free license for something people need, a replacement will often be developed (although I agree with several posters who have pointed out that it would be even better to just fix the license on the existing product). But if there is a somewhat-bad, or mostly-free license for something, people are severly undermotivated to do anything to replace it.
My interaction with MySQL has been like this for years. They have fixed the license now, but previously, their license didn't make any sense (free ($$) for non-commercial use and some kinds of commercial use, if you could figure it out; open source but not freely redistributable, except older versions which were GPL's). This mess made PostgreSQL appealing for years (not to raise the old flamefest--I do know that MySQL lacks subselects and transactions and I do miss them dearly. I don't trust it for big stuff but it works great for small stuff).
Anyone else think of additional examples of mediocre licenses killing development?
When does Debian plan to incorporate the LVM (Logical Volume Manager) tools into a standard release. It would be nice to see this along with the MD (Multiple Devices) working well together.
Fascinating answers. I really appreciated getting the detailed (if somewhat repititious) view of the whole thing.
For me, the most interesting aspect is how much Havenco and Sealand are relying on the UK to protect it's (now) territorial waters and container port for them. This makes complete sense, but it's not something i'd thought of before. It will be very interesting to see how this develops.
Final kvetch: child pornography. This one is just too vague to be enforceable, even within jurisdictions that have a larger body of law to clarify this. If Havenco works out, I think that this clause will cause trouble eventually.
Networks on the internet have nothing to do with hardware. really. it's all about peering. the network that our service was switched to doesn't have NAP peering, doesn't have good european peering, doesn't have squat. it's not a real network on a par with UUnet. It's more of a verio sort of a network (not really what we signed up for).
One very important thing that I haven't seen mentioned yet: as a result of the purchase of USW, Qwest is spinning off their entire Internet services division covering the 14-state US West region. I know because we were a Qwest subscriber and last week they unceremoniously moved us from Qwest's AS number to the old Colorado Supernet AS number (Qwest bought colorado supernet about 3 years ago).
This is bad for a bunch of us for a bunch of reasons. It means that Qwest's main IP network (everything outside of the 14-state territory) will be decent and only slightly diminished. The IP network that gets spun off, however, sucks. It is a rinky little regional network (and certainly not the network we signed up for).
Just as a side note: they are also spinning off their voice long distance business. I got a letter a few weeks ago from a no-name called 'Touch America' or something like that telling me that they were my new LD provider. Needless to say, I switched to someone who would give me something free to switch.
Has anyone else experienced problems with these spinn-offs yet? Are there other services spinning off that I haven't mentioned here?
The real question is 'will they actually develop it and make it work?'. The reason it's a question is that IBM has been releasing code to the community for a little while now and targetting it at Linux, but they have not put sufficient developer time into making it work.
Their JFS (journalling file system) is a good example of this. released quite some time ago, no effort to port it to current versions on the kernel and no apparent discussion about that is going on.
The LVM could be similar. *IF* they had released the LVM last year and *IF* they had supported it with a reasonable amount of programming resources we might care (and I say this as a person who has used and *loved* IBM's LVM on AIX). On the other hand, if they just release the code but don't support the transition and don't make an active effort to participate in community development of it, who cares?
Contrast this to SGI who, for all of their failings as a company, are releasing code *and* supporting its inclusion into the kernel through active participation in the linux-kernel list, web sites and other mailing lists. I'd like to see IBM get on board in the same way.
The core tennants of trademark law have nothing to do with intellectual property. Trademarks are not intellectual property in any way (there is no content to them). Trademarks are words and symbols associated with a company and its products. You may be confusing Trademark law with Patent or Copyright law.
So here's the issue (and maybe I didn't make my point clearly enough): if you have a restaurant called McDonald's and I have a software company called McDonald's, we know that consumers will not be confused between the two (you sell greasy burgers and I sell buggy software--no comparison, right?).
Now comes the web. McDonalds.com is just a commercial domain. It does not distinguish what kind of business it is. It's just commercial. You and I both plausibly have a right to the domain and both of us arguably confuse each others customers by using it.
Slashdot Mirror
I'm sorry but I think this grossly misses several points and undermines the appropriate difference between threads and processes.
One way to think of threads is as a solution to bloated processes. In operating systems like Solaris, which are designed to scale to 32 or 64 (or more) processors, the number of locks in the kernel is enormous. As a result, context switches and process creation time tend to be higher. In gross terms, you pay for the concurrency at high numbers of processors with poor performance at lower numbers of processors. This is not necessarily bad (especially if you plan to use 16 or more processors at some point) but it is just the way things are.
Linux, on the other hand, penalizes scalability for large numbers of processors in order to get much better performance with smaller numbers of processors. Linux does this because Linus doesn't believe that 16+ processor machines are common or sensical and that the kernel should be optimized for common (and sensical) cases.
Why do I mention all of this? Because Linux process creation times are slightly faster than Solaris thread creation times. Anyone who fetishizes multi-threading versus multi-processing doesn't really understand the difference between the two and when it really matters.
Processes are contexts of execution. Threads are contexts of execution that may share a memory space with other contexts of execution. These are fundamentally different things in some operating systems. In Linux, a thread is just a process that shares a memory space with another process. This is because processes are *fast* to create and switch to in Linux (optimized for the common case, remember?).
Anyway, I don't mean to bash maraist at all, just to point out a common set of misconceptions about these things. When considering these architectures, each database system must try to optimize across all of the operating systems they plan to be deployed on (just like the apache project, which i think was an excellent analogy).
I should say at the outset: I've used both Postgres and MySQL on production projects and like both for very different reasons. But here's the thing (and this is a common problem with technology product evaluations): these products have very different design goals and aren't really that comparable.
I'm not saying the standard "MySQL's not a database because it doesn't support transactions and databases have to. ACID!" (although I'm sympathetic to that point of view, I don't think individual words like "database" are worth fighting over--If MySQL wants to call itself a database, fine). What I am saying is that Postgres was designed to be a full-fledged SQL92-compliant database with transactions and triggers and foreign keys and the whole lot. MySQL was designed to be a SQL-based front-end to a very fast database file format. These products are not the same and comparing them without agknowledging that seems foolish.
I've been very pleased by the speed improvements in Postgres recently (partisan testing aside, Postgres 7 really is much faster). I've also been impressed by feature additions in MySQL (although it still isn't close to what you would expect to get if you're coming from the Oracle or DB2 world). But both remain inherently died to their design goals. This isn't a bad thing, at all, because different projects need different products with different design goals.
I compare this to the (often senseless) comparisons of NetBSD, OpenBSD and FreeBSD. One is designed for portability, another for security (features be damned!) and the last for performance, features and multi-processing under (primarily) intel. Although they come from a common code base, they have obviously diverged in design goals. Instead of bashing one product or another (all of the *BSD's and the two databases discussed have *major* problems that are bashable) use the one that seems most appropriate to your needs.
I'll admit it: I'm still a twofish fan. I look at the number of rounds required to make rijndael reasonably secure and compare that to twofish and i don't feel happy. This is not to say that I don't think that Rijndael is secure now--it clearly is. This is also not to say that I think there's some good way to reliably determine the likely future security of uncracked algorithms--I think there is not. Nevertheless, we can guess about future security based on things like complexity (where twofish scores poorly) and number of rounds required for security (where twofish scores extremely well and rijndael does not).
There were two lurking decision factors in the AES that concern me:
1) patents. it has not been made clear how much the hitachi claimed patent affected the outcome.
2) embedded devices. i believe that the decision was weighted in favor of current embedded memory and computational power, which doesn't make any sense. Embedded applications will be more powerful by the time anyone actually implements this stuff and I'd much rather have something that is excellent on real computers and fine on smart cards, but that doesn't seem to be what we've ended up with.
Anyway, I'm glad to see the process was open and all kvetching aside, Rijndael is a *huge* improvement over DES or even DESX or tripleDES. The authors of all algorithms deserve congratulations.
what i find hillarious is that the translation still only really makes sense if you already speak some German. not much, mind you. I have two semesters of college german 8 years ago, but it is necessary.
o n.html) that shows how challenging this stuff is.
Two funny things: the first is verb order. German puts verbs at the end of phrases and sentences. eg: "he thinking about other things walked" or "after i working had finished tired i was". Given that this is an incredibly standard sentence pattern in German, you'd think an automatic translation engine that knew something about grammar and parts of speech could move stuff around (English is one of the most word-order sensitive languages in the world due mostly to our lack of other correlational clues such as gender and mood and our relatively weak cojugation of verbs. english-speakers *need* good sentence order to understand things in a way that spanish or arabic speakers are more flexible about).
second thing: simple words missing. 'Jetzt' means now. i knew this after a few weeks of german education. this should not be hard to translate. 'guten taste' is actually 'good taste'. my point here is that the translation engine seems to barf on simple words for no apparent reason. wired mag had an excellent article a while ago on machine translation (at http://www.wired.com/wired/archive/8.05/translati
i'm not really complaining because i find the translation a wonderful bridge between two semesters of german and being able to read the whole article. i can actually *read* and *understand* the article in the translation. i don't believe that someone with no german could do that very well yet. but this stuff is getting there.
In the long run, we all know that what will count is OS support. IBM has a strong, stated linux strategy, but we'll see where it goes.
Don't get me wrong, I am one of the few who actually like AIX. I think it's a mature, useful operating system with some really cool characteristics (fairly integrated hw support and debugging, excellent logical volume manager (better than veritas, imho)). nevertheless, it remains to be be seen whether IBM can actually bring Linux to their whole server platform (including these bad boys).
(There have been instruction set changes in the IBM processor line in the past, particularly between the POWER, POWER2 and POWER3 architectures, so I'm interested to see what the differences in this instruction set are...).
One other thing i thought of that hasn't really been discussed (probably because a disgusting majority of slashdotters are male and are not very gender-aware): are on-call policies gender biased?
women are more likely to have family responsibilities (whether children or elderly, we rely, as a society, on women to take care of everyone). as a result, it may be more difficult for them to take care of on-call duties than it is for men.
does anyone work anywhere where on-call policies are sensitive to these sorts of considerations (not gender, specifically, obviously, but different amounts of time that different people spend on caring for family members)?
I work for a medium-sized regional ISP. We have three call rotations (plus one for senior management): systems, networking and customer service (we don't operate a 24x7 call center). The call rotates through departments of 4-5 people, so everyone is on-call every 4-5 weeks.
We compensate people by paying them an extra day (8 hours) for each week on call at their current rate (everyone is salaried, so there's no easy way to pay them a multiple of current hourly rate.
There's not really differential compensation for what people do when they're on call but if it's really busy most managers give people comp time.
Does this seem fair?
So Germany and France are both very close to either strongly preferring or requiring open source software for certain kinds of government implementations (or so we've heard). OTOH, i've read that most US federal agencies are strongly perferring COTS (Commercial Off The Shelf) software solutions with a minimum amount of integration and custom code written.
This is the challenge that open source actually solves fairly well and fairly directly: COTS products are preferred because government agencies (and most private organizations as well) have a proven inability to develop software (they just write crappy code, manage their projects poorly and usually never finish). Given this environment, they'd like to 'just buy' everything (My slogan is that although you can do almost anything, you can't "just" do anything--integration is tough and no amount of management ignoring it will change that).
On the other hand, we read stories like this (and this one if funny, but hardly unique) about governments getting srewed by the commercial software vendors they use.
Open source splits this right down the middle--you get competent people to develop your products but you get access to the source to make changes if you want. cool, eh? government agencies who are nervous about this kind of thing can take a middle ground of establishing reliance on open protocols and requiring commercial vendors to support them.
I think anyone who has followed the development of the samba project over the past few years, even at a distance, can understand this fork. samba, as a project, is necessarily somewhat schizophrenic. On the one hand, the primary reason is to "emulate" file and print services provided by the microsoft platform. On the other hand, i think that the developers would like to provide an independently valuable server platform.
But samba, as a project, has not quickly been able to adapt new funcitonality provided by microsoft. encrypted passwords and PDC functionality are good example.
People in the open-source community are rightfully jittery about forks, but I think that this one could make sense. On the one hand, we get the main samba project persuing the goal of just having a great file sharing server platform. On the other hand, we have a lighter-weight project with the specific goal of just acheiving W2K full interoperability. I think this could be cool.
For a long time digital (and now compaq) have claimed that their optimizing compiler for the alpha was dramatically better than gcc. Does anyone know if this is still the case?
I know of several large alpha cluster installations (including the cplant at sandia national labs with over 1300 alpha processors!--http://www.cs.sandia.gov/cplant/), but it's never been clear that alphas really hit the price/performance curve for *integer* performance. Outside of scientific computing, floating point performance just doesn't matter that much. What matters is integer throughput and my recollection is that when considering SpecINT/$, Intel and related boxes are just cheaper.
Finally, there's the issue of datedness and market timeliness. Alpha has been around for forever and has just not really taken off in any big way, as far as I can tell. With W2K and NT dropping alpha support and no intel-killing performance on the horizon (unless wildfire is everything they crack it up to be), it seems unlikely that it will storm the market. alpha is the past. transmeta is the future ( I *know* they're aimed at completely different markets and have different design goals, but buzz is buzz and there's only so much of it to go around for processors. i don't think alpha will get any more.
Let me first say that, in general, I welcome this change to CERT policies. CERT announcements have become increasingly less relevant as the bugtraq list has grown and as the SecurityFocus team has added better tools for tracking and researching vulnerabilities. One interpretation of this change is that it represents a desperate cry for relevance by the CERT folx.
Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.
An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?
Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).
The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.
In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).
Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.
It's simple: Redhat (as several other distributions are now doing) is shipping a different compiler for compiling kernels than for general compilation.
You need to edit the kernel Makefile and add the line CC=kgcc (making sure that kgcc is installed on your system). kernel compilations will then proceed without problems.
Although this is surprising to many users, it's actually a good idea. The linux kernel stresses a compiler in ways that a regular program (even something like all of gnome) just can't do. Kernel compilation demands correctness of inlined functions, or preprocessor command parsing, of lock orders. Basically, the kernel uses C as a convenient macro language for assembly much of the time. The compiler's job is to faithfully translate.
Given all of that, the compiler that you want for general purpose compilation is not necessarily the compiler that compiles the kernel best. The kernel and compilers co-evolve. If you follow either the linux-kernel list or any of the gcc or libc lists, you will see that when bugs turn up with kernel compilation, it is as often the case that there is a libc or a gcc bug as a kernel bug. These bugs frequently only turn up in the context of a kernel compile (because who the hell else would do something like that?!?)
Finally, on the subject of the redhat release: RedHat did some dubious things (calling their gcc gcc 2.96 when 2.96 just doesn't exist, thereby forcing the gcc project to renumber their release to 2.97 just to catch any RedHat bugs, eg.). However, I'm steadily impressed by Redhat as a distro (flame me if you want, I don't care). Redhat is a commercial distribution but they release *all* the software they develop as gpl open source (and have set the tone among other distributors to do the same), and have struck a good balance between novelty and stability.
Anyway, that's how to solve your kernel compiling problem (among lots of other stuff).
Point well-made. However, if we want to get really pedantic, the system OS/390 is either an operating system or a platform, and VM is a meta-operating system (or operating sytem) that runs on system OS/390 and Linux runs under VM. :-) Gosh, these IBM folx are strange, but they do good stuff sometimes.
This is not actually that surprising. IBM has a stated goal of making linux run on every piece of hardware and every platform they sell, from the top of the line (OS390) to the bottom (intel-based netfinity line, I guess).
So there are two things going on here: 1) IBM has their own version of Unix that's quite good but not doing very well in the marketplace. 2) IBM has decided that Linux is the way to unseat Sun's dominance of the midrange server market.
Given those two facts, supporting yet a different version of Unix designed primarily for the Itanium platform (regardless of what they say about also running on the Power chip) doesn't make any sense. Even IBM has limited resources.
The web site has links to previous projects to give you some ideas about the kind of work that some of the teams have done, but overall I will say that the work is of remarkably high quality. This is a school-year-long event, so many of the projects will need to be shortened for semester-long use. They may also need to be made more simple.
As a side note, I should mention that although all of the projects can benefit from supercomputer time, the Challenge is over 10 years old as a program now. As a result, most of the projects run find on mid-range desktops (but are, neverthless, computationally intensive tasks).
It's present in the 2.4 kernel we're shipping.
This doesn't really address the issue. I know that I'm harping about this LVM stuff, but I've mentioned it a couple of times wrt to redhat and seem to have been misunderstood both times.
Here's the deal: RedHat should ship an operating system with and LVM-aware installer and LVM-tools that can create partitions across disks and resize partitions and filesystems without a reboot. It should do this in the default install (while allowing people to get out of it if they want fdisk-style partitioning).
Logical Volume Management is pretty much the holy grail of filesystem management (and anyone who's used AIX, HPUX or the veritas tools on solaris will agree).
I just want to make it clear that shipping a 2.4pre kernel on the 2nd CD with logical volume patches just doesn't cut it. Suse started shipping with the LVM and tools two minor revs ago now.
I haven't installed it yet, but it looks as thought the Logical Volume Manager tools still aren't packaged with the distro. This concerns me. This is among several concerns I have about RedHat's future directions. I've always liked redhat (since the Mother's Day release back in the day) and especially have appreciated their attempt to balance the new and fancy with stability and security.
But recently they've been failing on both fronts. Suse seems to be taking the lead on new features (with their support of X drivers, and shipping LVM and reiserfs), and Redhat has slipped on the security front. Redhat took two weeks (two weeks!) to issue patches the the last round of security problems affecting the 2.2.14 kernel. Not the 24-hour turnaround I've come to expect.
I suspect the distro will be good in other respects, though.
I love the palm. I've had a III for ages and really appreciate what it does well (and am fairly irked by the few things it doesn't do well).
But this connectivity model is for the birds. The recurring costs are high, the PQA infrastructure is not an open standard (as far as I can tell) and it's too easy to go over the limit. The model of the VII just doesn't work for me (I like the design and size of the V better anyway).
What we need is something the size and weight of teh V with color with full net access for $15 / month (how much data could you really transport with that damned stylus). The US would really do well to get off our collective butts, scrap our analog cell phone network, finish building some of the digital networks, and then allow them to be used for packet-switched data.
The point that the article seems to leave out, though, is that mediocre (or almost-free) licenses (like Sun's Community Source License, just to pick on one) are even worse for the community.
If there is a totally non-free license for something people need, a replacement will often be developed (although I agree with several posters who have pointed out that it would be even better to just fix the license on the existing product). But if there is a somewhat-bad, or mostly-free license for something, people are severly undermotivated to do anything to replace it.
My interaction with MySQL has been like this for years. They have fixed the license now, but previously, their license didn't make any sense (free ($$) for non-commercial use and some kinds of commercial use, if you could figure it out; open source but not freely redistributable, except older versions which were GPL's). This mess made PostgreSQL appealing for years (not to raise the old flamefest--I do know that MySQL lacks subselects and transactions and I do miss them dearly. I don't trust it for big stuff but it works great for small stuff).
Anyone else think of additional examples of mediocre licenses killing development?
When does Debian plan to incorporate the LVM (Logical Volume Manager) tools into a standard release. It would be nice to see this along with the MD (Multiple Devices) working well together.
Fascinating answers. I really appreciated getting the detailed (if somewhat repititious) view of the whole thing.
For me, the most interesting aspect is how much Havenco and Sealand are relying on the UK to protect it's (now) territorial waters and container port for them. This makes complete sense, but it's not something i'd thought of before. It will be very interesting to see how this develops.
Final kvetch: child pornography. This one is just too vague to be enforceable, even within jurisdictions that have a larger body of law to clarify this. If Havenco works out, I think that this clause will cause trouble eventually.
This misses the point.
Networks on the internet have nothing to do with hardware. really. it's all about peering. the network that our service was switched to doesn't have NAP peering, doesn't have good european peering, doesn't have squat. it's not a real network on a par with UUnet. It's more of a verio sort of a network (not really what we signed up for).
One very important thing that I haven't seen mentioned yet: as a result of the purchase of USW, Qwest is spinning off their entire Internet services division covering the 14-state US West region. I know because we were a Qwest subscriber and last week they unceremoniously moved us from Qwest's AS number to the old Colorado Supernet AS number (Qwest bought colorado supernet about 3 years ago).
This is bad for a bunch of us for a bunch of reasons. It means that Qwest's main IP network (everything outside of the 14-state territory) will be decent and only slightly diminished. The IP network that gets spun off, however, sucks. It is a rinky little regional network (and certainly not the network we signed up for).
Just as a side note: they are also spinning off their voice long distance business. I got a letter a few weeks ago from a no-name called 'Touch America' or something like that telling me that they were my new LD provider. Needless to say, I switched to someone who would give me something free to switch.
Has anyone else experienced problems with these spinn-offs yet? Are there other services spinning off that I haven't mentioned here?
The real question is 'will they actually develop it and make it work?'. The reason it's a question is that IBM has been releasing code to the community for a little while now and targetting it at Linux, but they have not put sufficient developer time into making it work.
Their JFS (journalling file system) is a good example of this. released quite some time ago, no effort to port it to current versions on the kernel and no apparent discussion about that is going on.
The LVM could be similar. *IF* they had released the LVM last year and *IF* they had supported it with a reasonable amount of programming resources we might care (and I say this as a person who has used and *loved* IBM's LVM on AIX). On the other hand, if they just release the code but don't support the transition and don't make an active effort to participate in community development of it, who cares?
Contrast this to SGI who, for all of their failings as a company, are releasing code *and* supporting its inclusion into the kernel through active participation in the linux-kernel list, web sites and other mailing lists. I'd like to see IBM get on board in the same way.
I absolutely disagree here.
The core tennants of trademark law have nothing to do with intellectual property. Trademarks are not intellectual property in any way (there is no content to them). Trademarks are words and symbols associated with a company and its products. You may be confusing Trademark law with Patent or Copyright law.
So here's the issue (and maybe I didn't make my point clearly enough): if you have a restaurant called McDonald's and I have a software company called McDonald's, we know that consumers will not be confused between the two (you sell greasy burgers and I sell buggy software--no comparison, right?).
Now comes the web. McDonalds.com is just a commercial domain. It does not distinguish what kind of business it is. It's just commercial. You and I both plausibly have a right to the domain and both of us arguably confuse each others customers by using it.
Does that make sense?