I will now summarize this entire article into two opposing viewpoints:
SOAP is great - it lets you work around those annoying firewalls and get stuff done on port 80!
SOAP is wrong - firewalls are there for a reason, and just running everything on port 80 doesn't make it any more secure.
I tend to agree with the second argument, but until we have powerful stateful protocol filters for all protocols that could go through port 80 or wherever, there's no real difference between opening 50 separate holes or one big one. Even then, bad stuff can get in and out over https, etc. So SOAP doesn't really make things much worse, it just points out security issues that we've been ignoring all along.
I guess I still see it as a non-issue; users wouldn't even notice that firewalling was compiled into their Linux distribution's kernel either, check the box and a script would echo "1" to all the appropriate/proc/sys/net/ipv4/* fields. It's true that you would have to rebuild and reboot the Linux kernel to go from non-firewall to firewall; but on the other hand I'd be surprised if Windows can turn this on without a reboot either.
It is a good question as to why this can't be a Linux kernel module, though. Or maybe it can in 2.4; I'm still sticking with 2.2 here so I wouldn't know.
That's a bad analogy - if your kernel came with firewalling compiled in, and your distribution had a nice checkbox, you could do the same thing. The only difference is that you can entirely remove the firewalling code from Linux (not just turn it off, actually make your kernel smaller) if you want to. You can't get into the internals of Windows XP and do that as easily.
Hint: don't tell Grandma what you're going to do, just ssh in and tell her it will be fixed in a half hour. Recompile, install, reboot, add firewall rules, and you're done.
I'll point out that GnuCash has a Scheme-based user preference setting which does handle a lot of this, including different kinds of options, specifying defaults, etc. It doesn't really do prerequisite handling the way that CML does, though. But if I were going to rip off a user preferences config system from somewhere, I think I would start there.
That is why (well, one of the reasons) Daylight Savings Time is a giant hoax that should never have been perpetrated upon the American people. I curse the day that I moved away from Indiana, one of the few places in the Union that doesn't suffer from changing the damn clocks twice a year.
Um, what do you have against morticians? They have a job to do that many of us wouldn't like to do, but that doesn't put them in the same league as deliberate slime like spammers and recording industry executives. Unless you've had a bad embalming experience that we don't know about:)
I agree that it isn't too hard to do if you pick the right tools up front, and I think many other posters on this story have adequately corroborated that point. I just don't see why to aim for such portability if it is not a real requirement - you can get things done more cheaply and complete your testing cycle much faster if there is not a multiplatform requirement. All I'm saying is to not create more work for yourself than you need.
Also, I think that starting on *nix and porting to Windows may be a much easier port than Windows->Unix - if you're not careful, Microsoft's development tools will not allow you an easy port away from Windows. So in my thinking the worst case is starting with NT and going to *nix, a slightly better case is starting with *nix and going to NT, and the best case is write it all on the targetted platform, and if you have to provide a GUI on other platforms make it web- or Java-based.
Re:Sad, sad commentary
on
XBox Released
·
· Score: 1
In this case, it's "rather the devil we don't know, than the devil we do" - Microsoft public relations at work:)
The correct question: "why are our requirements so f***ed up?"
Seriously - there is absolutely no reason to develop on NT, test on NT, and deploy on Unix, and there are a number of good reasons not to follow that path. If you're going to deploy on Unix, you can develop the system on Unix using cheap hardware and more-or-less free Linux or *BSD development systems. You are setting yourself up for about twice as much work as you need to be - just develop the thing on Linux or *BSD to begin with, stick with standard Unix portability guidelines (there are a couple of good *nix portability guides out there from O'Reilly, although at the moment I can't remember the associated cover animals), and call it good. Don't add extra portability into the plan that doesn't really buy you anything.
I could understand if you foresee a future need to port back to Windows, but absent such a requirement at the present, I really think you want to plan the easiest development plan that's consistent with your current deployment requirements. Just ditch the whole NT thing entirely, or if it's a matter of "well, we already bought you these NT boxes to use", then reformat them and install Linux or *BSD on them. Even in the worst case, moving *nix code to Windows will be less painful than moving Windows code to *nix - Unix is designed for portability somewhat, Windows is specifically designed to make it harder to port applications to other platforms. That is not where you want to start out from.
Also, if you do have to do the Windows thing, don't test on NT, test on 2000. In the 2-year timeframe that you're aiming for, nobody's going to want to actually run on NT. So if Windows must be in the picture, then develop on 2000, test on 2000, and deploy on 2000. Again, save yourself from some headaches that aren't necessary.
Um, that was just as funny as the parent comment, which was moderated up. Oh well.
O for a muse of humor, that would ascend
the brightest heaven of slashdot,
A weblog for a stage, trolls to act,
and moderators to behold the swelling scene!
The problem is that when people get training in "databases", they only hear about SQL, and thus that's all they know. At least that's my theory. What really needs to be taught is DB theory, followed by an investigation of the various implementations and standards, so that people can see what the alternatives are and which ones work in which cases.
Thanks - somebody just posted the pages on a bulletin board around here and I was too lazy to go back and figure out what paper it came out of and on what date. Even better that it's in the WSJ, and was a really professionally-done spot IMHO. It's strange how I can go from disgust at Microsoft's marketing weasels to admiration for IBM's in so short a span:)
Interestingly enough, just this morning I saw a two-page ad for IBM servers running linux. I haven't found the actual ad online, but it showed the famous "bigfoot" photo, labeled as fake, and then a penguin walking through the server room in the same pose, labeled as real. The other page of the ad was an abbreviated list of the usual Linux myths that we all know and love, with IBM-specific arguments as to why these were no longer true. This is the real fruit of the $1 billion campaign from IBM, and a great answer for your hesitant management.
Maybe this isn't entirely on-topic, but I thought it was a great example of some more of that good mindshare. And this time IBM isn't going to have to scrub off any sidewalk paint:)
Well, unless Linux no longer includes kernel development tools and package managers, there's no reason that you can't leave the bloat out of Linux. Let's see that happen with Windows. It won't, because a lot of the bloat is devoted to customer lock-in, not customer-requested features.
The free software community seems to be in a bit of a sticky point right now. We can no longer be completely
ignored. However, the bigger we get, the more attention and fire we're going to get, and we're not really equipped
to defend ourselves yet. It would nice to suddenly be the same size as Microsoft, to have that much power and
influence, but the only way to get that influence is go through this very impenetrable gauntlet. It's a real
Catch-22.
Here's the thing: free software is immune to Microsoft's normal kind of attacks. They can't buy it out, and although they can out-market it, the best and original Linux marketing was all word-of-mouth. Microsoft can't destroy free software as long as there remains one free software developer. They can only hope to contain it by competing on the basis of price and features. And competing with something that's free will eventually sap their strength, one way or the other.
Slashdot Mirror
No problem - the DOJ just needs to read at +1 :)
Is that the one that was used to track down a bunch of errors in the Linux kernel sources? It kind of sounds like the same thing.
Have a nice retirement! :)
I will now summarize this entire article into two opposing viewpoints:
I tend to agree with the second argument, but until we have powerful stateful protocol filters for all protocols that could go through port 80 or wherever, there's no real difference between opening 50 separate holes or one big one. Even then, bad stuff can get in and out over https, etc. So SOAP doesn't really make things much worse, it just points out security issues that we've been ignoring all along.
I think that is this article's most insightful comment so far. cf also the comment above where Bruce Schneier points this out.
So all of the naked+petrified trolls around here are Jedi too? Man, the Dark Side of the Force really is a harsh master :)
I guess I still see it as a non-issue; users wouldn't even notice that firewalling was compiled into their Linux distribution's kernel either, check the box and a script would echo "1" to all the appropriate /proc/sys/net/ipv4/* fields. It's true that you would have to rebuild and reboot the Linux kernel to go from non-firewall to firewall; but on the other hand I'd be surprised if Windows can turn this on without a reboot either.
It is a good question as to why this can't be a Linux kernel module, though. Or maybe it can in 2.4; I'm still sticking with 2.2 here so I wouldn't know.
That's a bad analogy - if your kernel came with firewalling compiled in, and your distribution had a nice checkbox, you could do the same thing. The only difference is that you can entirely remove the firewalling code from Linux (not just turn it off, actually make your kernel smaller) if you want to. You can't get into the internals of Windows XP and do that as easily.
Hint: don't tell Grandma what you're going to do, just ssh in and tell her it will be fixed in a half hour. Recompile, install, reboot, add firewall rules, and you're done.
I'll point out that GnuCash has a Scheme-based user preference setting which does handle a lot of this, including different kinds of options, specifying defaults, etc. It doesn't really do prerequisite handling the way that CML does, though. But if I were going to rip off a user preferences config system from somewhere, I think I would start there.
That is why (well, one of the reasons) Daylight Savings Time is a giant hoax that should never have been perpetrated upon the American people. I curse the day that I moved away from Indiana, one of the few places in the Union that doesn't suffer from changing the damn clocks twice a year.
Um, what do you have against morticians? They have a job to do that many of us wouldn't like to do, but that doesn't put them in the same league as deliberate slime like spammers and recording industry executives. Unless you've had a bad embalming experience that we don't know about :)
I agree that it isn't too hard to do if you pick the right tools up front, and I think many other posters on this story have adequately corroborated that point. I just don't see why to aim for such portability if it is not a real requirement - you can get things done more cheaply and complete your testing cycle much faster if there is not a multiplatform requirement. All I'm saying is to not create more work for yourself than you need.
Also, I think that starting on *nix and porting to Windows may be a much easier port than Windows->Unix - if you're not careful, Microsoft's development tools will not allow you an easy port away from Windows. So in my thinking the worst case is starting with NT and going to *nix, a slightly better case is starting with *nix and going to NT, and the best case is write it all on the targetted platform, and if you have to provide a GUI on other platforms make it web- or Java-based.
In this case, it's "rather the devil we don't know, than the devil we do" - Microsoft public relations at work :)
The correct question: "why are our requirements so f***ed up?"
Seriously - there is absolutely no reason to develop on NT, test on NT, and deploy on Unix, and there are a number of good reasons not to follow that path. If you're going to deploy on Unix, you can develop the system on Unix using cheap hardware and more-or-less free Linux or *BSD development systems. You are setting yourself up for about twice as much work as you need to be - just develop the thing on Linux or *BSD to begin with, stick with standard Unix portability guidelines (there are a couple of good *nix portability guides out there from O'Reilly, although at the moment I can't remember the associated cover animals), and call it good. Don't add extra portability into the plan that doesn't really buy you anything.
I could understand if you foresee a future need to port back to Windows, but absent such a requirement at the present, I really think you want to plan the easiest development plan that's consistent with your current deployment requirements. Just ditch the whole NT thing entirely, or if it's a matter of "well, we already bought you these NT boxes to use", then reformat them and install Linux or *BSD on them. Even in the worst case, moving *nix code to Windows will be less painful than moving Windows code to *nix - Unix is designed for portability somewhat, Windows is specifically designed to make it harder to port applications to other platforms. That is not where you want to start out from.
Also, if you do have to do the Windows thing, don't test on NT, test on 2000. In the 2-year timeframe that you're aiming for, nobody's going to want to actually run on NT. So if Windows must be in the picture, then develop on 2000, test on 2000, and deploy on 2000. Again, save yourself from some headaches that aren't necessary.
flies: "Ah, my compound eyes! The goggles do nothing!"
Um, that was just as funny as the parent comment, which was moderated up. Oh well.
...and their own wire.
The problem is that when people get training in "databases", they only hear about SQL, and thus that's all they know. At least that's my theory. What really needs to be taught is DB theory, followed by an investigation of the various implementations and standards, so that people can see what the alternatives are and which ones work in which cases.
Spoken like someone who's never had sex :)
Thanks - somebody just posted the pages on a bulletin board around here and I was too lazy to go back and figure out what paper it came out of and on what date. Even better that it's in the WSJ, and was a really professionally-done spot IMHO. It's strange how I can go from disgust at Microsoft's marketing weasels to admiration for IBM's in so short a span :)
Not only that, they're calling it "free software" all over the place. Those bastards! :)
That is definitely not news. These are people who have worked long and hard to be able to turn on and off their Windows and Mac machines :)
Interestingly enough, just this morning I saw a two-page ad for IBM servers running linux. I haven't found the actual ad online, but it showed the famous "bigfoot" photo, labeled as fake, and then a penguin walking through the server room in the same pose, labeled as real. The other page of the ad was an abbreviated list of the usual Linux myths that we all know and love, with IBM-specific arguments as to why these were no longer true. This is the real fruit of the $1 billion campaign from IBM, and a great answer for your hesitant management.
IBM's main page for this, aimed at upper brass rather than engineering, is at http://www.ibm.com/linux/cio2, and the myths seemed to come from this brochure: http://www.ibm.com/linux/Demystifying_Linux_Brochu re.pdf.
Maybe this isn't entirely on-topic, but I thought it was a great example of some more of that good mindshare. And this time IBM isn't going to have to scrub off any sidewalk paint :)
Well, unless Linux no longer includes kernel development tools and package managers, there's no reason that you can't leave the bloat out of Linux. Let's see that happen with Windows. It won't, because a lot of the bloat is devoted to customer lock-in, not customer-requested features.
Here's the thing: free software is immune to Microsoft's normal kind of attacks. They can't buy it out, and although they can out-market it, the best and original Linux marketing was all word-of-mouth. Microsoft can't destroy free software as long as there remains one free software developer. They can only hope to contain it by competing on the basis of price and features. And competing with something that's free will eventually sap their strength, one way or the other.