Hmmmm..... you seem not to understand how the liquidity effect happens.
consider the money stored in charitable foundations. Typically those are setup as true "foundations" according to the law, and that involves a couple of things:
The foundation must spend a certain percentage of its assets every year. This usually means funding programs, which employ people, who spend more money, etc. This ends up having the same effect as government spending, which is probably the biggest promotor of growth in an otherwise stagnant economy. If you build a wing on a library, you have to hire people to build it, design it, clean it, buy books, etc.
The foundation invests the money it hasn't been spending in order to maintain the foundation. While this money isn't then used actively, it has the same money multiplier effect as if I just sat there and invested on ETrade.
Now consider someone who just sits there on his money. If they're really serious about wealth protection, it's in bond funds, money markets, annuities, etc., which are all probably in some offshore country (switzerland, Luxembourg, the Caymans, etc.). This has some money multiplier effect, but less than spending a large portion of it every year, and is probably less likely to help than maintaining the endowment of a foundation, because it's being held elsewhere in low-yielding investments.
I'm not arguing for a tax-the-rich policy. I think that it's largely wrong to overly tax inheritance, and the example of France shows that it just transfers money to corporations (look at family wineries in France....there are very few of any size remaining, because the inheritance laws encourage sell-offs to corporations and require splitting the land if you have multiple children). That's not very good either.
But don't say that having scions just holding all money is a positive economic effect. Your high school economics class may have taught you something, but obviously not THAT much.
He's already said that the hospital has a policy that critical care/services are not provided under email.
Have you ever seen a hospital that relied on email for things like medical care? If it's time critical, they'll page the doctor/pharmacist and use the phone.
Most hospitals are very paper-bound, mostly because they need written records and it's not usually good to carry palmtops around everywhere.
But you probably knew that going into the job (if you're an intern, you've almost certainly been around recently enough to watch St. Elsewhere, and maybe even ER before you got into medicine).
Yep, that system completely sucks. Yes, it's probably quite a bit of a "I had to do my time, now so should you." (kind like learning Scheme, IMHO). But you probably knew that going in, and once you're through the intern phase you'll never do it again.
Saying that you HAVE to go through that (and you don't....if you're a competant programmer you could do that for a living and make a quite nice salary) and that others should grow up isn't quite fair. If they all of a sudden told you, mid-way through your internship, that you'd have to start staying up every 4th night, you'd probably fight back quite seriously.
Unfortunately, this is a common refrain that I've heard whenever dealing with technical people. It's like squeezing water from a stone: no matter how hard you squeeze it, without fundamentally changing the nature of the stone (and turning it into a sponge or something) you're never going to get more out of it.
Explain to them that your people aren't robots/computers, and you can't just add load to them without changing something. Tell them that if they institute this policy, people WILL quit, and the cost of replacing them will be prohibitive.
But perhaps you should phrase it in an analogy that they can understand. Let's say that they have 100 beds in the hospital. Let's say that it's a VERY well-run hospital and they're running a 90% utilization rate. The hospital only covers non-emergency care (i.e. no Trauma ward in the ER). Now the hospital wants to start taking Trauma cases. Maybe the ER itself can handle it, but they probably don't have enough beds for the additional load. They probably don't have enough nurses, additional doctors, etc.
They can't make the decision to take trauma cases just based on the ER....they have to look at the WHOLE hospital's ability to handle the increased load.
The issue with additional 24-7 support of email is very similar. They can say that they're going to do it, but without providing additional resources, it can't actually be done. If they want to offer trauma care, they have to be able to handle the whole thing, add additional beds, nurses, etc. This is the same thing.
The problem is that the people you're dealing with probably don't understand it on the same level. They just think of services, and think that they can just add them for free.
The most difficult thing to do, but probably the correct one, is to have the person running the on-call program categorically refuse to do it. If you stand together, unless they just fire the lot of you (which they KNOW they won't do) you've got a lot of leverage there.
Make your best case. Speak logically, use analogies, use numbers. When all else fails, make blatant, explicit ultimatums and refusals. You wouldn't tell them how to run medical care, they shouldn't tell you how to run a support centre.
While the pedants at many universities have decided that this is the Best Book to teach people how to program (and that's always how they label it) learning to think in lambda calculus and fake objects using lambdas is really never the way to go. I asked once why they did it, and the response was that:
It's the only way to beat recursion into your brain so badly you'll never forget it.
I had to study it at the MIT AI lab and since that was the best place ever, so should you.
We have to get some higher level concepts into you before you do 3.5 more years of nothing but C++ and C and assembler.
If people are going to insist on teaching something trivial in the beginning, why must it be scheme? Why not Python? It gives most of the same features (even lambda calculus) and is just so much easier to learn and prepare for C++ or Java. Perl doesn't really do either.
The fusing process ain't perfect. If you put a laser-printed thing under a plastic sheet (like in a binder) much of the toner will stick to the plastic better than the paper and come off.
My bigger problem is wallets. When something's that close to your body (whether it's in your wallet, in your shirt pocket, in a jacket pocket, etc.) it's picking up body heat. The additional body heat will break down with some of the fusion process, and you'll get bits of toner which fall off.
It's not pleasant, and I try to avoid it when possible.
No one's arguing that someone shouldn't write an exploit, or that there should be some way of stopping some from writing or distributing it.
What they're claiming is that it's not necessarily wise for anyone to continue to distribute it.
In other words, you may have the right to stand up on a soap box and say whatever you want. But I don't have to give you the soapbox.
Okay, so if someone's a racist, he should stand up in a press conference and use a racial slur against someone, when he's a major political leader?
What about an ethnic or religious slur?
First of all, I sincerely doubt that you really think that politicians should always speak their mind whatever's on it, especially when it comes to matters like this. That would do nothing but lower the level of public discourse until we're hearing nothing but personal insults. At least in the status quo, they thinly veil things and we have at least some modicum of respectability amongst our elected leaders. Sure, not much, but enough.
Second, do you really mean that? Do you really mean that Dick Armey making a slip of the tongue in front of a microphone is him speaking his conscience? Note that he didn't stand up and say "I think Barney Frank is a evil person and his actions disgust me and may God have mercy on his soul." THAT even I would have had at least SOME respect for.
But no. He himself bit his tongue until he finally came out with something that showed his true side. And THAT is truly awful.
If you're so thrilled to speak your conscience, why oh why are you posting anonymously?
The problem here is that while Armey is actually complaining against the Carnivore review, he's not doing it for the right reasons (okay, ANY reason to oppose it is right IMHO, but this one is less right).
Let's consider some of the things he did say:
Members of the team have political ties.
Names weren't removed correctly.
That's all well and good, but let's look at the laundry list of problems he didn't mention:
The premise of Carnivore is a violation of civil liberties just by its existance.
Most of the people involved aren't engineers, they're politicos (just academic politicos).
Allowing the authors to choose the reviewers AT ALL won't ever work if you want unbiased reviews.
Keeping the process secret simply encourages people to come up with conspiracy theories which will never EVER be dispelled.
That just doing things like winnowing and chafing will remove any ability for Carnivore to do its job.
Ordinarily, I'm not one to look a gift horse in the mouth. But considering some of the things that Dick Armey's mouth has spouted (the Barney Frank incident comes to mind immediately), I'm not willing to take this as a victory.
We want to win this by fighting on the right issues, not turning it into a political football. The moment it becomes a purely partisan battle, the larger issue is ignored and lost to all of us.
Obviously you're not that up on US patent law. Unlike most other countries (Japan for example) patents aren't public knowledge until they're granted. Pending patents aren't released by the USPTO.
This has its bad points and good points, but the important thing is that unless we break the law, we can't get copies of patents before they're granted. So even if an absurd patent is filed, only the Monkeys working for the USPTO have access to it before it's granted. If they're not smart enough (or diligent enough, which is the real case) to accurately assess the patent, then it goes through uncontested.
The sad thing is that the US thinks this is such a Good Idea(tm) that it's trying to force this absurd concept on the rest of the world.
I've been using ReiserFS on top of Software-RAID0 on my development machines (two Ultra-160 10k RPM drives) and it's insanely fast. Compiles of our code went down by about 10%, which considering that up until that point we were running builds at 100% CPU utilization is quite an accomplishment! I've never had any problems, and our tests are even faster (we have some tests which create about 1,000 - 100,000 files in the same directory, and then process all of them). It's been great.
The one problem that I've had is that I upgraded my primary machine to be SMP, and I'm running now two PIII-933mhz processors. Sure enough, as soon as I did this and did a stress test (our application is completely unforgiving on the file system, with enormous amounts of multithreaded O_SYNC read/write calls and network access), I exposed the "IPI synch" bug on 2.2.15.
My only problem with reiserFS is that it exposes this bug, which means that I pretty much have to upgrade my OS by patching it or moving to 2.4.0, which is easier said than done once you decide to make the silly decision to install mandrake in "high security" mode, which gives you the silly mdksecure kernel which is virtually impossible to reinstall cleanly over.
(sorry for the double post, this is to the first half of the comment).
It depends on how pervasive the code changes have to be. If it involves #ifdeffing every single file, then it's going to be very difficult to maintain that, and it's going to be very unlikely that the maintainers of the project are going to allow that feature to remain part of the major distribution.
That problem is a dual-edged sword. It also means that maintaining one big patch is a complete nightmare. Every version of the kernel that comes out has to be separately patched, with two important considerations:
The code which needs to be inserted has to be reinserted. If this is all separate files, that's easy, but if it's not that's a complete nightmare. And the code to call into that separate file is then a nightmare.
Any changes which have broken the patch have to be investigated and possibly changed. If you're working on filesystem patches, for example, someone working on the core fs work may have broken your patch without your knowing it, because they're not including your code in their coding/debugging process. So every time there's a change to the kernel, you have to figure out whether that change will potentially break your work.
The only way to resolve the second is to keep the patch inside the actual kernel, so that the authors of the rest of the system are aware of it, and will either try their best not to break it, or will do first-round of changing the new functionality to work with their changes.
Basically, it comes down to how pervasive the work has to be. If it's a really pervasive change which touches on almost everything, then the only option from a software engineering perspective is a fork. Anything else is being done from a feel-good PR perspective, because it just doesn't make any sense from a technical perspective to try to maintain a huge patch that covers everything.
Not really. Forks are also justified if the maintainer has effectively abandoned the project and refuses to relinquish it (and someone else has to "seize" control to make sure that it continues to go forward).
Just as importantly, forks are probably necessary when a significant part of the user/developer base disagrees with the direction of the project. This usually implies that the forked version and the original version are aiming at solving different problems within the same vein. If the original project wants to continue in the original direction and some people want to use the source to solve a slightly different project, then they pretty much have to fork in order for the project to achieve its maximal result of being most useful to the most people.
This isn't a bad thing if it's done right. It's just that most of the big forks you hear of are at least partially the result of bitter, angry wars (OpenBSD anyone?). You don't hear that much about the ones which are completely amicable.
For applications developers, having one stable unix-like system to develop applications on is a huge win. Although you can say that with Posix all things are possible, it seldom works that way.
I'm working on an open source project, and porting to anything beyond *Linux (i.e. AlphaLinux, IntelLinux, etc.) is a pain in the ass. Header files aren't where you think they are, they don't necessarily do what you think they do, standard library routines don't do what you think they do (try getcwd(NULL, 0) on a solaris) or what they're supposed to do, etc.
When companies like Oracle employ teams of porting engineers and have to substantially modify their coding practices (last time I read them, the Oracle coding standards were over 100 pages) to support the plethora of operating systems they have to support, you start to see the advantage of having one unified platform. One of the reasons why corporate developers have flocked to Java in droves was the original goal of Write Once, Run Everywhere.
While there are specific hardware differences between platforms that porters should be aware of (Alignment is the most significant and obvious), being able to have the same operating system on many different platforms gives developers more of an advantage to writing to that platform. And it makes more esoteric hardware more attractive (becuase they get to exploit all the different applications ported to that platform).
Overall, the more things that Linux runs (and runs well) on, the better it is for applications developers to support the Linux development model and encourage customers to run it.
The solution isn't to just say "Tru64 is better, run it" but to say "Linux needs work, here's the help," which appears to be what Compaq/DEC is doing here.
The problem here is not that the source is open, and that people can make changes to it. The problem is that there are problems in the software which allow it to be exploited.
If the FTPd in question had been rigorously inspected and reviewed, it wouldn't be able to be hacked like that. If the protocol which is being spoofed had authentication, encryption, etc., it wouldn't be spoofed as easily.
If anything, using open source leads to higher quality releases, one step beyond. While the software in question might not be perfect in 1.0 or 1.1, by 1.2 or 1.3 they've probably fixed the issues which allow it be easily cracked/hacked. And if there are serious protocol issues, 2.0 will probably solve those.
Sorry to respond to blatant trolling, but as long as Back Orifice exists, your claim is completely without merit.
My partner happens to be an non-immigrant alien (a whole different visa status, don't ask... he's even worse off than someone with an H1-B). We're both men. Had one of us been a different gender,
We would have been married by now,
We probably wouldn't have been attracted to each other in the first place.:-)
The reliance on marriage as a backdoor has left some of my friends contemplating getting their partners married off in a sham wedding to an American Lesbian who wants a European Passport. Don't laugh, it happens.
Just wanted to point out that for some Americans, it's not that easy at all.
The founders of the US were very careful to not create a national U.S. language (historical tip: if they were going to, it was more likely to be German than English). They thought that doing so would limit the ability to have immigrants assimilate quickly, and enforce subtle discrimination against those who didn't speak the dominant language.
I highly recommend you come to someplace like San Francisco which has many neighborhoods where English is the minority.
I've met quite a few people from Bangalore and other parts of India who have better grasp of the English language than most people I meet when visiting rural areas of America. They may speak with an accent, they may have misspeaks sometimes, but their general grasp of the nuances of the English Language and its formative literary history is much better than the average graduate of the average U.S. high school.
I've had significant problems with windows demoware. Often the demoware writers will "hide" a registry key somewhere which they look for later, so that you can't do multiple demo installs (particularly for time-limited demos).
Tri-Plus WinSpace, which I used at a job which forced me to use NT, did this famously. I tried a beta, and they had to send me instructions on hacking my registry to install the full version because the beta (demo) had a broken installer.
So perhaps you haven't had to do this, but trust me, other people have. Perhaps you just haven't lived life on the cutting edge enough to do this sorta thing, but I've had to do it several times.
1. I don't think that it's ever okay to be in a position where ACID properties might be violated. I know that it's inevitable in the case of bugs, but it really should be strenuously avoided.
2. Even if you do look at that, what about if Alan Cox checks in a minor bug fix to something that will keep a certain driver from crashing in some situation which will only happen on average once every 2 years? The point is that people DO care about fixing bugs, and that there IS public acclaim for people doing that.
3. What about somebody writing a new DataBlade which allows you to have semantically more interesting responses to things (like the CIDR type in PostGres)? I think that's a lot of help, and it's the sort of thing which is most akin to the device driver thing. Somebody issuing a new driver which supports a new bit of hardware is always issued praise for it (as long as the driver doesn't suck).
4. What about if somebody writes a new sorter which is 20% faster than the old one? Same scenario as the Alan Cox example... There are a lot of things in databases where you can get very quick performance enhancements which people will recognize and see every day, whether it's in query optimization, execution, drivers..... If all you care about is performance hacks, there are so many places to look at in a database that it's hard to know where to begin!
In my opinion, I think you're mistaking what are the sort of really CORE bits which some truly dedicated people are going to work on (like the networking system, the file system stuff, etc.) and what are useful modular systems which are akin to software drivers.
Besides, one of the things that you're ignoring is that there are a lot of people who are paid to work on bits of open source projects which aren't quite as glamorous as the others. Think of the HelixCode/Eazel guys. Do you think that every single one of their engineers is paid to just work on highly visible, glamorous stuff? Of course not. But if they can get people interested in the glitzy stuff, then they can more wisely invest their development efforts on the things that are likely NOT goign to get done by random open source guy (like an ACID fix).
You might believe it when you see it, but the winds are changing and I think it's just a matter of time before this sort of thing happens to an RDBMS.
A properly designed enterprise-class RDBMS is actually a perfect candidate for this kind of development. The problem is that existing RDBMSes aren't designed that way.
Consider the Illustra/Informix DataBlade stuff. It makes perfect sense to consider a DataBlade the equivalent of a Linux driver (same with Postgres plugins). As long as the interface is well defined and adhered to, the people developing the datablade kernel don't have to have strict control over the datablades.
The problem is that RDBMSes were designed in the 70s and 80s when modular code wasn't really in vogue. And even if they were, there are minor performance tweaks you can get if you ignore modularization in favor of an additional 1% bump in your TPC-C numbers.
If there were an RDBMS which was designed correctly, it would be a perfect candidate for open source development, as long as there was somebody sitting around saying "This version is stable enough to run your business on", which is the equivalent of the Linus/Alan system of test releases and final kernel versions.
Just because Oracle is designed wrong doesn't mean that the basic premise is any less sound.
Sorry, but as long as you can find another company which will sponsor you (and transferring is MUCH easier for a company than getting a fresh H1-B), you can transfer to any company. H1-Bs are most certainly transferrable.
In my experience here in Silicon Valley, while things are extremely expensive, people are paid appropriately. Even the office manager/administrative assistant at my company is paid more than $50k a year.
Let's face it. Things in Silicon Valley are so tight that if people are competant, they can get a great job at another firm paying them a living wage just by snapping their fingers. If they're not competant, then they're stuck. But with the number of technology firms which need to have more people than they can hire, I've not found anybody who's that good who's making $50k in the Valley. It just doesn't happen.
I think that there's a huge disconnect here (myself falling into that trap) between people working in corporate IT (who may be getting hosed by their employers) and people working for development firms (who are in extremely short supply).
I don't think that at least in the development industry (I don't know about hte Big Corporate IT Worker part), out here in Silicon Valley, there really is a shortage of qualified people.
There are a lot of companies (mine included [shameless plug]) which will, quite literally, hire any competent people it can get its hands on. We pay relocation costs for people outside our area, we look into telecommuting for people who don't want to relocate, we pay egregiously high salaries.
None of that matters, because the bodies aren't available. We will look at people who have H1-B visas, we will look at people who are not currently in the software industry, we'll look at anybody who can help us grow. The people aren't available.
I think one of the central disconnects here is the difference between software development firms (who simply need good people and can't find them) and non-software-firms (who might be doing some bad things, but I don't know).
As long as we keep the distinctions between teh two, the debate can go on. Otherwise it's ships passing in the night.
In case anybody's interested in the benchmark that they ran, it's AS3AP, which is a pretty independant benchmark. I VERY seldom see anybody run it, but it's here:
Slashdot Mirror
consider the money stored in charitable foundations. Typically those are setup as true "foundations" according to the law, and that involves a couple of things:
The foundation must spend a certain percentage of its assets every year. This usually means funding programs, which employ people, who spend more money, etc. This ends up having the same effect as government spending, which is probably the biggest promotor of growth in an otherwise stagnant economy. If you build a wing on a library, you have to hire people to build it, design it, clean it, buy books, etc.
The foundation invests the money it hasn't been spending in order to maintain the foundation. While this money isn't then used actively, it has the same money multiplier effect as if I just sat there and invested on ETrade.
Now consider someone who just sits there on his money. If they're really serious about wealth protection, it's in bond funds, money markets, annuities, etc., which are all probably in some offshore country (switzerland, Luxembourg, the Caymans, etc.). This has some money multiplier effect, but less than spending a large portion of it every year, and is probably less likely to help than maintaining the endowment of a foundation, because it's being held elsewhere in low-yielding investments.
I'm not arguing for a tax-the-rich policy. I think that it's largely wrong to overly tax inheritance, and the example of France shows that it just transfers money to corporations (look at family wineries in France....there are very few of any size remaining, because the inheritance laws encourage sell-offs to corporations and require splitting the land if you have multiple children). That's not very good either.
But don't say that having scions just holding all money is a positive economic effect. Your high school economics class may have taught you something, but obviously not THAT much.
Yep, that system completely sucks. Yes, it's probably quite a bit of a "I had to do my time, now so should you." (kind like learning Scheme, IMHO). But you probably knew that going in, and once you're through the intern phase you'll never do it again.
Saying that you HAVE to go through that (and you don't....if you're a competant programmer you could do that for a living and make a quite nice salary) and that others should grow up isn't quite fair. If they all of a sudden told you, mid-way through your internship, that you'd have to start staying up every 4th night, you'd probably fight back quite seriously.
Explain to them that your people aren't robots/computers, and you can't just add load to them without changing something. Tell them that if they institute this policy, people WILL quit, and the cost of replacing them will be prohibitive.
But perhaps you should phrase it in an analogy that they can understand. Let's say that they have 100 beds in the hospital. Let's say that it's a VERY well-run hospital and they're running a 90% utilization rate. The hospital only covers non-emergency care (i.e. no Trauma ward in the ER). Now the hospital wants to start taking Trauma cases. Maybe the ER itself can handle it, but they probably don't have enough beds for the additional load. They probably don't have enough nurses, additional doctors, etc.
They can't make the decision to take trauma cases just based on the ER....they have to look at the WHOLE hospital's ability to handle the increased load.
The issue with additional 24-7 support of email is very similar. They can say that they're going to do it, but without providing additional resources, it can't actually be done. If they want to offer trauma care, they have to be able to handle the whole thing, add additional beds, nurses, etc. This is the same thing.
The problem is that the people you're dealing with probably don't understand it on the same level. They just think of services, and think that they can just add them for free.
The most difficult thing to do, but probably the correct one, is to have the person running the on-call program categorically refuse to do it. If you stand together, unless they just fire the lot of you (which they KNOW they won't do) you've got a lot of leverage there.
Make your best case. Speak logically, use analogies, use numbers. When all else fails, make blatant, explicit ultimatums and refusals. You wouldn't tell them how to run medical care, they shouldn't tell you how to run a support centre.
While the pedants at many universities have decided that this is the Best Book to teach people how to program (and that's always how they label it) learning to think in lambda calculus and fake objects using lambdas is really never the way to go. I asked once why they did it, and the response was that:
If people are going to insist on teaching something trivial in the beginning, why must it be scheme? Why not Python? It gives most of the same features (even lambda calculus) and is just so much easier to learn and prepare for C++ or Java. Perl doesn't really do either.
My bigger problem is wallets. When something's that close to your body (whether it's in your wallet, in your shirt pocket, in a jacket pocket, etc.) it's picking up body heat. The additional body heat will break down with some of the fusion process, and you'll get bits of toner which fall off.
It's not pleasant, and I try to avoid it when possible.
In other words, you may have the right to stand up on a soap box and say whatever you want. But I don't have to give you the soapbox.
What about an ethnic or religious slur?
First of all, I sincerely doubt that you really think that politicians should always speak their mind whatever's on it, especially when it comes to matters like this. That would do nothing but lower the level of public discourse until we're hearing nothing but personal insults. At least in the status quo, they thinly veil things and we have at least some modicum of respectability amongst our elected leaders. Sure, not much, but enough.
Second, do you really mean that? Do you really mean that Dick Armey making a slip of the tongue in front of a microphone is him speaking his conscience? Note that he didn't stand up and say "I think Barney Frank is a evil person and his actions disgust me and may God have mercy on his soul." THAT even I would have had at least SOME respect for.
But no. He himself bit his tongue until he finally came out with something that showed his true side. And THAT is truly awful.
If you're so thrilled to speak your conscience, why oh why are you posting anonymously?
Let's consider some of the things he did say:
- Members of the team have political ties.
- Names weren't removed correctly.
That's all well and good, but let's look at the laundry list of problems he didn't mention:- The premise of Carnivore is a violation of civil liberties just by its existance.
- Most of the people involved aren't engineers, they're politicos (just academic politicos).
- Allowing the authors to choose the reviewers AT ALL won't ever work if you want unbiased reviews.
- Keeping the process secret simply encourages people to come up with conspiracy theories which will never EVER be dispelled.
- That just doing things like winnowing and chafing will remove any ability for Carnivore to do its job.
Ordinarily, I'm not one to look a gift horse in the mouth. But considering some of the things that Dick Armey's mouth has spouted (the Barney Frank incident comes to mind immediately), I'm not willing to take this as a victory.We want to win this by fighting on the right issues, not turning it into a political football. The moment it becomes a purely partisan battle, the larger issue is ignored and lost to all of us.
This has its bad points and good points, but the important thing is that unless we break the law, we can't get copies of patents before they're granted. So even if an absurd patent is filed, only the Monkeys working for the USPTO have access to it before it's granted. If they're not smart enough (or diligent enough, which is the real case) to accurately assess the patent, then it goes through uncontested.
The sad thing is that the US thinks this is such a Good Idea(tm) that it's trying to force this absurd concept on the rest of the world.
The one problem that I've had is that I upgraded my primary machine to be SMP, and I'm running now two PIII-933mhz processors. Sure enough, as soon as I did this and did a stress test (our application is completely unforgiving on the file system, with enormous amounts of multithreaded O_SYNC read/write calls and network access), I exposed the "IPI synch" bug on 2.2.15.
My only problem with reiserFS is that it exposes this bug, which means that I pretty much have to upgrade my OS by patching it or moving to 2.4.0, which is easier said than done once you decide to make the silly decision to install mandrake in "high security" mode, which gives you the silly mdksecure kernel which is virtually impossible to reinstall cleanly over.
But ReiserFS rocks!
It depends on how pervasive the code changes have to be. If it involves #ifdeffing every single file, then it's going to be very difficult to maintain that, and it's going to be very unlikely that the maintainers of the project are going to allow that feature to remain part of the major distribution.
That problem is a dual-edged sword. It also means that maintaining one big patch is a complete nightmare. Every version of the kernel that comes out has to be separately patched, with two important considerations:
- The code which needs to be inserted has to be reinserted. If this is all separate files, that's easy, but if it's not that's a complete nightmare. And the code to call into that separate file is then a nightmare.
- Any changes which have broken the patch have to be investigated and possibly changed. If you're working on filesystem patches, for example, someone working on the core fs work may have broken your patch without your knowing it, because they're not including your code in their coding/debugging process. So every time there's a change to the kernel, you have to figure out whether that change will potentially break your work.
The only way to resolve the second is to keep the patch inside the actual kernel, so that the authors of the rest of the system are aware of it, and will either try their best not to break it, or will do first-round of changing the new functionality to work with their changes.Basically, it comes down to how pervasive the work has to be. If it's a really pervasive change which touches on almost everything, then the only option from a software engineering perspective is a fork. Anything else is being done from a feel-good PR perspective, because it just doesn't make any sense from a technical perspective to try to maintain a huge patch that covers everything.
Just as importantly, forks are probably necessary when a significant part of the user/developer base disagrees with the direction of the project. This usually implies that the forked version and the original version are aiming at solving different problems within the same vein. If the original project wants to continue in the original direction and some people want to use the source to solve a slightly different project, then they pretty much have to fork in order for the project to achieve its maximal result of being most useful to the most people.
This isn't a bad thing if it's done right. It's just that most of the big forks you hear of are at least partially the result of bitter, angry wars (OpenBSD anyone?). You don't hear that much about the ones which are completely amicable.
I'm working on an open source project, and porting to anything beyond *Linux (i.e. AlphaLinux, IntelLinux, etc.) is a pain in the ass. Header files aren't where you think they are, they don't necessarily do what you think they do, standard library routines don't do what you think they do (try getcwd(NULL, 0) on a solaris) or what they're supposed to do, etc.
When companies like Oracle employ teams of porting engineers and have to substantially modify their coding practices (last time I read them, the Oracle coding standards were over 100 pages) to support the plethora of operating systems they have to support, you start to see the advantage of having one unified platform. One of the reasons why corporate developers have flocked to Java in droves was the original goal of Write Once, Run Everywhere.
While there are specific hardware differences between platforms that porters should be aware of (Alignment is the most significant and obvious), being able to have the same operating system on many different platforms gives developers more of an advantage to writing to that platform. And it makes more esoteric hardware more attractive (becuase they get to exploit all the different applications ported to that platform).
Overall, the more things that Linux runs (and runs well) on, the better it is for applications developers to support the Linux development model and encourage customers to run it.
The solution isn't to just say "Tru64 is better, run it" but to say "Linux needs work, here's the help," which appears to be what Compaq/DEC is doing here.
If the FTPd in question had been rigorously inspected and reviewed, it wouldn't be able to be hacked like that. If the protocol which is being spoofed had authentication, encryption, etc., it wouldn't be spoofed as easily.
If anything, using open source leads to higher quality releases, one step beyond. While the software in question might not be perfect in 1.0 or 1.1, by 1.2 or 1.3 they've probably fixed the issues which allow it be easily cracked/hacked. And if there are serious protocol issues, 2.0 will probably solve those.
Sorry to respond to blatant trolling, but as long as Back Orifice exists, your claim is completely without merit.
The reliance on marriage as a backdoor has left some of my friends contemplating getting their partners married off in a sham wedding to an American Lesbian who wants a European Passport. Don't laugh, it happens.
Just wanted to point out that for some Americans, it's not that easy at all.
I highly recommend you come to someplace like San Francisco which has many neighborhoods where English is the minority.
I've met quite a few people from Bangalore and other parts of India who have better grasp of the English language than most people I meet when visiting rural areas of America. They may speak with an accent, they may have misspeaks sometimes, but their general grasp of the nuances of the English Language and its formative literary history is much better than the average graduate of the average U.S. high school.
Tri-Plus WinSpace, which I used at a job which forced me to use NT, did this famously. I tried a beta, and they had to send me instructions on hacking my registry to install the full version because the beta (demo) had a broken installer.
So perhaps you haven't had to do this, but trust me, other people have. Perhaps you just haven't lived life on the cutting edge enough to do this sorta thing, but I've had to do it several times.
1. I don't think that it's ever okay to be in a position where ACID properties might be violated. I know that it's inevitable in the case of bugs, but it really should be strenuously avoided.
2. Even if you do look at that, what about if Alan Cox checks in a minor bug fix to something that will keep a certain driver from crashing in some situation which will only happen on average once every 2 years? The point is that people DO care about fixing bugs, and that there IS public acclaim for people doing that.
3. What about somebody writing a new DataBlade which allows you to have semantically more interesting responses to things (like the CIDR type in PostGres)? I think that's a lot of help, and it's the sort of thing which is most akin to the device driver thing. Somebody issuing a new driver which supports a new bit of hardware is always issued praise for it (as long as the driver doesn't suck).
4. What about if somebody writes a new sorter which is 20% faster than the old one? Same scenario as the Alan Cox example... There are a lot of things in databases where you can get very quick performance enhancements which people will recognize and see every day, whether it's in query optimization, execution, drivers..... If all you care about is performance hacks, there are so many places to look at in a database that it's hard to know where to begin!
In my opinion, I think you're mistaking what are the sort of really CORE bits which some truly dedicated people are going to work on (like the networking system, the file system stuff, etc.) and what are useful modular systems which are akin to software drivers.
Besides, one of the things that you're ignoring is that there are a lot of people who are paid to work on bits of open source projects which aren't quite as glamorous as the others. Think of the HelixCode/Eazel guys. Do you think that every single one of their engineers is paid to just work on highly visible, glamorous stuff? Of course not. But if they can get people interested in the glitzy stuff, then they can more wisely invest their development efforts on the things that are likely NOT goign to get done by random open source guy (like an ACID fix).
You might believe it when you see it, but the winds are changing and I think it's just a matter of time before this sort of thing happens to an RDBMS.
Consider the Illustra/Informix DataBlade stuff. It makes perfect sense to consider a DataBlade the equivalent of a Linux driver (same with Postgres plugins). As long as the interface is well defined and adhered to, the people developing the datablade kernel don't have to have strict control over the datablades.
The problem is that RDBMSes were designed in the 70s and 80s when modular code wasn't really in vogue. And even if they were, there are minor performance tweaks you can get if you ignore modularization in favor of an additional 1% bump in your TPC-C numbers.
If there were an RDBMS which was designed correctly, it would be a perfect candidate for open source development, as long as there was somebody sitting around saying "This version is stable enough to run your business on", which is the equivalent of the Linus/Alan system of test releases and final kernel versions.
Just because Oracle is designed wrong doesn't mean that the basic premise is any less sound.
Sorry, but as long as you can find another company which will sponsor you (and transferring is MUCH easier for a company than getting a fresh H1-B), you can transfer to any company. H1-Bs are most certainly transferrable.
Let's face it. Things in Silicon Valley are so tight that if people are competant, they can get a great job at another firm paying them a living wage just by snapping their fingers. If they're not competant, then they're stuck. But with the number of technology firms which need to have more people than they can hire, I've not found anybody who's that good who's making $50k in the Valley. It just doesn't happen.
I think that there's a huge disconnect here (myself falling into that trap) between people working in corporate IT (who may be getting hosed by their employers) and people working for development firms (who are in extremely short supply).
There are a lot of companies (mine included [shameless plug]) which will, quite literally, hire any competent people it can get its hands on. We pay relocation costs for people outside our area, we look into telecommuting for people who don't want to relocate, we pay egregiously high salaries.
None of that matters, because the bodies aren't available. We will look at people who have H1-B visas, we will look at people who are not currently in the software industry, we'll look at anybody who can help us grow. The people aren't available.
I think one of the central disconnects here is the difference between software development firms (who simply need good people and can't find them) and non-software-firms (who might be doing some bad things, but I don't know).
As long as we keep the distinctions between teh two, the debate can go on. Otherwise it's ships passing in the night.
http://www.benchmarkresources.com/handbook/5.html
Of course they can charge you nothing for the support there. ;-)
Kirk