So you write your.NET programs in C# and guess what? You're locked into MS's proprietary API's (not to mention all of the native calls you're probably making)...
Java has standardized and created a spec and compatibility tests for their entire system end to end..NET has no such thing. They standardized the steering wheel and the brake pedals so that they can sucker you into getting locked into the rest of the car.
This is why there are many JVM's, including a FS/OS one which is nearly complete (and certainly farther along than Mono is and may ever be) - and why the same isn't true for.NET.
That's just the first reference I found. I've seen position papers where they go even further to sell the ease of use of their unmanaged interop like a feature... so have you probably.
Old saw indeed. What's so surprising about it? The interop and unmanaged code features get big billing... why do you think that is? So no one will use them?
Again, what is your reason for saying that so categorically?
I'm surprised you would ask considering how thoroughly the "commonness" of the CLR has been debunked on/. (reference)
The fact that Python has been ported to JVM and.NET doesn't really speak to the point I'm trying to make here.
Ah, wondeful pessimism.
So I guess you just ignored the statements afterwards explaining the reasons for this pessimism?
There is no future in C#, because it's Microsoft's toy, and it will always be Microsoft's toy. If they want they can take it and go home. When MS decides its time to stop, as they did for many of their other much vaunted initiatives, then that's it, your party is over. Yes, I know about Mono. It doesn't matter.
With Java you can take your code anywhere. As the first widely adopted VM standard, Java is now taught in universities instead of C++ (and certainly C# isn't **widely** used in academia - MS nuts, notice the asterisks before flaming). Basically this adds up critical mass. The language is never going away. And because of its unique properties I predict it will have more staying power than most other languages. People will be porting that VM when we're all dead.
Java is well specified and unencumbered. Even the source of Sun's VM is available (though not under the GPL, at least you can read it, see what's going on in the VM, and fix bugs), and there are Gnu implementations that are farther along already than Mono - and I doubt Mono will catch up.
Based purely on raw numbers of job offers, if you're looking to make money off this skill you would be flipping crazy to learn C#... although OTOH once you know one, the other won't be too difficult.
C# people claim their language is "better." I've used both - C# is not better enough to justify the baggage of being locked into the world's most notorious vendor. In many cases the supposed advantages of C# are a wash or even bad ideas - such as their pointless and absurd practice of mixing VM and non-VM code at every opportunity, and allowing unsafe code to be mixed in... Thus eliminating the boundaries on the well-defined, well-tested native stack and ruining most of the advantages of a VM while keeping most of its disadvantages.
C# people claim their runtime is language agnostic. It is not. It's C* agnostic. Any language significantly different from a C/C++/Java-like language can't be supported efficiently. No surprise there.
I don't expect Mono to succeed even in its modest promises, although if they do, they may wish they didn't. Perhaps their best path will be to stop trying to be compatible and diverge into a kind of "dirty.NET"... All fun and games until MS sues them. And if you dismiss this as a conspiracy theory... and go to embrace the patented, "standardized" platform of the people who financed SCO anyway... you will certainly get what's coming to you, eventually.
Imagine if you order a box of catfood to be delivered that's worth about $10. And then the next day a crowd of 15 attorneys in suits arrive at your door with a 20 page contract, and the box. They won't give you the catfood until you agree to their "license." You can either call your own attorneys, if you have any, and spend several weeks evaluating their contract at the cost of several thousand dollars of your own money, or, they say, you can simply agree to the contract by blinking your eyes.
It turns out that there were worms in the catfood and now your cat is incredibly sick. Amazingly, the attorneys did this on purpose. If you take her to the vet, it will cost you hundreds of dollars to cure her. You don't remember blinking, but they swear you did.
The government has sent an angry letter to the catfood guys, but no one looks like they have any intention of paying your vet bill - or even sending your cat a get well card.
In response to the government, the catfood people announce they've "solved" the problem, because they've agreed to temporarily stop shipping worms in catfood. However, they're still shipping spiders, ants, and leeches - and they have "big plans" to expand the practice.
You don't know exactly how long your cat has left to live, but after watching all this, you get the feeling its days are numbered one way or another.
If it were me who tried to install spyware on people's PC's using music CDs, the answer would be yes.
On the other hand, if it were a wealthy multinational corporation who did so, the answer would be... perhaps we can find a discrete settlement to avoid any discomfort to our most valued citizens.
...this is a bit ridiculous on its face. Sure the spyware is illegal in about a dozen different ways (depending on your state) but... this all hinges on whether or not we accept or decline a EULA? How does that make sense?
That kind of reasoning by implication gives EULAs legitimacy which THEY DO NOT HAVE.
Since when under common law do we have such outrageously elaborate and suprising binding legal agreements by parties without equal representation?
Since when can agreement be given by pressing a mouse button or removing shrinkwrap?
The EULA itself is an ugly audacious legal fiction... this is why they needed UCITA to attempt to legitimize them after the fact.
This is nonsense. That whole "language-agnostic runtime" business has been debunked thoroughly here already. You can make any langauge in CLR you want, as long as it's basically like C# in structure. You can also make any language that's not, as long as you don't care about performance. Basically the same as the JVM.
I don't see people flocking to.NET to write anything other than C#, VB, and maybe, I heard about 1 Cobol project. Yes it's possible, nobody does it.
Then there's all the sugar for doing native calls and unmanaged code in the VM. Stupidest thing I've ever heard of. Basically, either everyone will use a bunch of native or unmanaged code and then most of the reasons to have a VM disappear, since you no longer have just the more highly trusted, verified VM stack to worry about, and no "cross platform," or no one uses it, because they see it's a dumb idea. In addition, there are tools for making JNI easier. But the reason nobody writes JNI isn't that it's hard, it's that it's stupid. If you need JNI, you probably don't need Java.
Maybe it's just me, but I don't find it that hard anyway..NET security I can't comment on. And as you say, language feature wise, C# and Java are similar. Java is clearly the older cousin; C# to me looks like something designed from the ground up to be just like it but with some incremental improvements. I wouldn't call it a "knock-off" but it's by no means an evolutionary leap either.
I can't understand your comment about app server pricing. It sounds like envy that there is no usable free or open source app server for.NET... And honestly the market for app servers (since there is a market, rather than vendor lock-in) is pretty varied, last I checked you could spend as much or as little as you wanted (though if you were going to buy a cheap java app server I'd say you're probably crazy in one way or another... use free or just use PHP for crying out loud)...
Re:I guess it depends on where you came from
on
Java Is So 90s
·
· Score: 1
Bah. Using that macro language to handle dependencies is absolutely absurd. You can say the disorganized mess that grew up around it and in it wasn't C/C++'s fault. I don't think its an accident that there was never at any time in any place a clear and comprehensive API that a C or C++ programmer could use. Let alone missing other kind of nice things like for instance astandardized String class that was actually used in said API. Or language level support for threading. Or what have you.
You have some good points and I always expected there'd be more direct-to-native Java, but as I learned more about how it worked, I began to realize that A) there are advantages, including potential performance advantages, to the VM, and B) the essential features that you want out of Java require something rather like a VM, whether or not you package it hidden in the EXE or separately.
But yes, ultimately, I think the future involves the lower-level platform native tools becoming less insane (and vaguely more "Java-like," although really just more organized and modern generally).
I guess it depends on where you came from
on
Java Is So 90s
·
· Score: 4, Insightful
After C/C++, Java ended a long nightmare of preprocessor abuse, ridiculous "APIs" (collections of warring header files with no-vowels function names that were never the same from computer to computer), especially GUI APIs (never failed to amaze me how someone could call Swing "stupid" and then go back to coding Win32 or Motif... Apple guys I can forgive:)... And then there was all the fun of the endless futility of "expecting" programmers to always get their own memory management right. That one really burns me.
C/C++ never took the rap for billions upon billions of dollars in lost productivity because of all the bizarre failure modes of memory allocation failures (hey, there's garbage on the screen... or, hey... it's Tuesday, the full moon is out and the app segfaulted again... coincidence?) or having some clever sixteen year old shove 80k up your 256 byte buffer. You can't tell me wrestling with the garbage collector isn't an improvement on this, because it's ridiculous.
Java of course is within spitting distance of C++ already in one or two benchmarks, but in reality nobody cared either way because you got things in trade that made it a good deal even when it was still quite slow. Not sure what "consistency of the output code" means, but...
You got it right about LAMP. The problems were often that the higher level systems (well, PHP anyway) were great for making websites, but didn't enforce enough rules to be a good idea for projects above a certain size. Still and all, a great many companies in the 90's said "OK, we need 8-way oracle boxes with hot swap CPUs and a 50 disk RAID and Oracle and Weblogic, and... now, what are we going to build exactly?" Most of these places could and should have just used PHP on a few pentiums and saved themselves time and money and headaches. On the other hand, I saw plenty of places coast on a slick of Perl and human blood well past the point where they needed real "enterprise" (hate that word) software development.
It seems like Java was only ever a victim of its own success. No one ever wrote a shitty applet or misused the VM in some way, where the whole language didn't get blamed as a result. Basically, it's another tool in the toolbox, and though it drives C/C++ guys to conniptions, it's the right choice to replace many applications programming tasks right now. Not that I wouldn't throw a party to meet its succeesor.
Unlike many big languages past, Java is probably never going away. No one seems to have realized it yet, but as the VM-first-mover it's the ultimate langauge standard. I bet you people will be porting the Java VM long after we're dead.;)
This article (and for that matter the writeup) sounds almost like the result of some graduate student AI experiment.
Looks like people are nostalgic for the glory days, when some fictional pseudotechnical concepts no one even understood could echo across boardrooms and bathroom stalls and stir venture capital investments and make you cool at parties.
Is there anything to this, at all, other than taking several unrelated, incremental and entirely unremarkable improvements in user interface and style and putting them in a fancy basket with a bottle of wine and a wedge of cheese?
I hoped we saw the last of that damn hippie-dippy Louis Rosetto school of engineering after the bomb. Powered by bright lights, ignorance and peer pressure.
Very true, although I think if you do the AL piece the way you're supposed to, where you're really forced to formally codify your assumptions about how your application interacts with clients (to the point where you can roll out a highly restrictive ruleset in production), that's actually something I'd call _part_ of good coding and code review. In no way a panacea, but the rigor, the redundancy, can be very beneficial.
I think I get it now. I think many people see those sections and head straight for an appliance like Teros as a "conclusive" way to demonstrate compliance with a lot of 6.5 and a few other ones. But you're right, the AL firewall is not specifically required.
Damn, I wish I could revise my post.:) Thanks, I learned something.
You're absolutely right. Of course, if the providers are smart, they won't let people get away with crippling the system, but time will tell on that... Different places will take it more or less seriously. You never get a magic box you can just plug in and get security for free. It only works when everyone begins to think about the security systems from the get-go. In my experience there is often something to be gained across the board (not just in security) from the simple practice of formally declaring your expectations about traffic patterns (to the point where you could feed those rules into an appliance for enforcement).
Eh? Nice link, but you didn't really read it I guess. I have seen PCI compliance many times which required truly comprehensive standards for IT security, and the use of a certified vendor like Teros, as well as a (quarterly) inspection by a certified inspection service and many other things. Picture an 80-item questionare where every answer has to be yes. And these are orgs with stellar fraud/CB stats.
I don't know what level you are. You may have lesser requirements if you don't have that much volume...
You might want to either do some reading in advance, or be a little more circumspect next time...
The larger point of database security measures notwithstanding, I think the days of the "dumb" application-blind firewall are over.
Most companies that handle credit cards in modest amounts are required by their providers to use application-aware systems like Teros, which inspect every detail of every transaction across the border at the highest levels - providing a redundant check in the form of a policy controlling things like what cookies and querystring values can accompany a request for a particular path, and looking for things like cookies appearing that you didn't set, or form values being submitted that weren't in the HTML form you sent out...
We thought we would finish this sooner... but we didn't.
Eventually we kind of gave up trying, but we're too nice to just take it off the website?
Who would have thought?
Or... my personal favorite:
"Beta" as a kludge to workaround users who don't read disclaimers and get hopping mad when things don't work. I swear that accounts for a big percentage of the people who do this.
Your university isn't a real business. It _sounds_ the classic case of where that kind of hacking _does_ happen.
I've seen a lot of real businesses use Linux (and Unix and OS's in general) by now. How many? Put it this way: way, way more than were involved in this study.:)
In an environment where downtime costs real money/goodwill, you work with the vendor on every aspect of your environment, or you don't work with that vendor at all, so those kinds of hacks are never seriously considered. This is so that when something goes wrong, you can blame the vendor and keep your job.
There's a lot of fancy ducking and dodging, none of which changes the facts that:
Whether you're crooked or not, you'll give the exact answers he gave about your ethics. We judge only by the work itself. If you asked me that question, that's what I'd say, not a lot of stuff I wouldn't expect anyone to believe.
The sample size is far too small to be meaningful in any way to anyone, yet he did the study anyway, knowing full well how Microsoft would "misrepresent" it afterwards (if it cut their way, assuming this was ever in doubt).
The work re. glibc done on the Linux boxes is absurd, unjustifiable, and utterly unrepresentative of normal Linux use. Yes, people hack their boxes up. But how many real business do that sort of thing in production?
Lego's invention is very old, and was patented a long time ago.
Patents live only so long. This is for a reason. Granting exclusive monopolies on things forever is not a good idea.
Lego's patent expired, long, long after they had recouped money orders of magnitude beyond what would induce others to attempt to innovate in that industry.
Other people started to make lego-like bricks.
Like a lot of monopolists, Lego became addicted to not having and not suffering competitors. They decided that they wanted to play lawyer games and try to keep others from competing with them rather than follow the law, and pretended that the studs on the bricks that make them work are "trademarked" by them...
The judge basically said, "Look, don't you even try that stunt in here. Your patent expired. The studs on the blocks are a mechanical feature, not a mark. Go away."
Slashdot Mirror
C# is a standard. .NET is not.
.NET programs in C# and guess what? You're locked into MS's proprietary API's (not to mention all of the native calls you're probably making)...
.NET has no such thing. They standardized the steering wheel and the brake pedals so that they can sucker you into getting locked into the rest of the car.
.NET.
So you write your
Java has standardized and created a spec and compatibility tests for their entire system end to end.
This is why there are many JVM's, including a FS/OS one which is nearly complete (and certainly farther along than Mono is and may ever be) - and why the same isn't true for
Bruce Eckel recently said
.NET Framework promotes interaction with COM components, COM+ services, external type libraries, and many operating system services..."
/. (reference)
.NET doesn't really speak to the point I'm trying to make here.
"C# 3.0 may be too forward-thinking for Java to catch up to."
Don't believe the hype.
Who is "they"?
Microsoft themselves, in their own developer literature.
"The Microsoft
link
That's just the first reference I found. I've seen position papers where they go even further to sell the ease of use of their unmanaged interop like a feature... so have you probably.
Old saw indeed. What's so surprising about it? The interop and unmanaged code features get big billing... why do you think that is? So no one will use them?
Again, what is your reason for saying that so categorically?
I'm surprised you would ask considering how thoroughly the "commonness" of the CLR has been debunked on
The fact that Python has been ported to JVM and
Ah, wondeful pessimism.
So I guess you just ignored the statements afterwards explaining the reasons for this pessimism?
There is no future in C#, because it's Microsoft's toy, and it will always be Microsoft's toy. If they want they can take it and go home. When MS decides its time to stop, as they did for many of their other much vaunted initiatives, then that's it, your party is over. Yes, I know about Mono. It doesn't matter.
.NET"... All fun and games until MS sues them. And if you dismiss this as a conspiracy theory... and go to embrace the patented, "standardized" platform of the people who financed SCO anyway... you will certainly get what's coming to you, eventually.
With Java you can take your code anywhere. As the first widely adopted VM standard, Java is now taught in universities instead of C++ (and certainly C# isn't **widely** used in academia - MS nuts, notice the asterisks before flaming). Basically this adds up critical mass. The language is never going away. And because of its unique properties I predict it will have more staying power than most other languages. People will be porting that VM when we're all dead.
Java is well specified and unencumbered. Even the source of Sun's VM is available (though not under the GPL, at least you can read it, see what's going on in the VM, and fix bugs), and there are Gnu implementations that are farther along already than Mono - and I doubt Mono will catch up.
Based purely on raw numbers of job offers, if you're looking to make money off this skill you would be flipping crazy to learn C#... although OTOH once you know one, the other won't be too difficult.
C# people claim their language is "better." I've used both - C# is not better enough to justify the baggage of being locked into the world's most notorious vendor. In many cases the supposed advantages of C# are a wash or even bad ideas - such as their pointless and absurd practice of mixing VM and non-VM code at every opportunity, and allowing unsafe code to be mixed in... Thus eliminating the boundaries on the well-defined, well-tested native stack and ruining most of the advantages of a VM while keeping most of its disadvantages.
C# people claim their runtime is language agnostic. It is not. It's C* agnostic. Any language significantly different from a C/C++/Java-like language can't be supported efficiently. No surprise there.
I don't expect Mono to succeed even in its modest promises, although if they do, they may wish they didn't. Perhaps their best path will be to stop trying to be compatible and diverge into a kind of "dirty
Imagine if you order a box of catfood to be delivered that's worth about $10. And then the next day a crowd of 15 attorneys in suits arrive at your door with a 20 page contract, and the box. They won't give you the catfood until you agree to their "license." You can either call your own attorneys, if you have any, and spend several weeks evaluating their contract at the cost of several thousand dollars of your own money, or, they say, you can simply agree to the contract by blinking your eyes.
It turns out that there were worms in the catfood and now your cat is incredibly sick. Amazingly, the attorneys did this on purpose. If you take her to the vet, it will cost you hundreds of dollars to cure her. You don't remember blinking, but they swear you did.
The government has sent an angry letter to the catfood guys, but no one looks like they have any intention of paying your vet bill - or even sending your cat a get well card.
In response to the government, the catfood people announce they've "solved" the problem, because they've agreed to temporarily stop shipping worms in catfood. However, they're still shipping spiders, ants, and leeches - and they have "big plans" to expand the practice.
You don't know exactly how long your cat has left to live, but after watching all this, you get the feeling its days are numbered one way or another.
If it were me who tried to install spyware on people's PC's using music CDs, the answer would be yes.
On the other hand, if it were a wealthy multinational corporation who did so, the answer would be... perhaps we can find a discrete settlement to avoid any discomfort to our most valued citizens.
Egregious Unbelievable Lawyer Audacity
...this is a bit ridiculous on its face. Sure the spyware is illegal in about a dozen different ways (depending on your state) but... this all hinges on whether or not we accept or decline a EULA? How does that make sense?
That kind of reasoning by implication gives EULAs legitimacy which THEY DO NOT HAVE.
Since when under common law do we have such outrageously elaborate and suprising binding legal agreements by parties without equal representation?
Since when can agreement be given by pressing a mouse button or removing shrinkwrap?
The EULA itself is an ugly audacious legal fiction... this is why they needed UCITA to attempt to legitimize them after the fact.
Wow, the same news broken in not only a newspaper, but a book too.
Holy shit, someone reboot my pacemaker.
What can I say, other than I think your comment is complete bullshit?
C++ _wishes_ it was radically different, but isn't, really. That's one if its bigger problems.
This is nonsense. That whole "language-agnostic runtime" business has been debunked thoroughly here already. You can make any langauge in CLR you want, as long as it's basically like C# in structure. You can also make any language that's not, as long as you don't care about performance. Basically the same as the JVM.
.NET to write anything other than C#, VB, and maybe, I heard about 1 Cobol project. Yes it's possible, nobody does it.
.NET security I can't comment on. And as you say, language feature wise, C# and Java are similar. Java is clearly the older cousin; C# to me looks like something designed from the ground up to be just like it but with some incremental improvements. I wouldn't call it a "knock-off" but it's by no means an evolutionary leap either.
.NET... And honestly the market for app servers (since there is a market, rather than vendor lock-in) is pretty varied, last I checked you could spend as much or as little as you wanted (though if you were going to buy a cheap java app server I'd say you're probably crazy in one way or another... use free or just use PHP for crying out loud)...
I don't see people flocking to
Then there's all the sugar for doing native calls and unmanaged code in the VM. Stupidest thing I've ever heard of. Basically, either everyone will use a bunch of native or unmanaged code and then most of the reasons to have a VM disappear, since you no longer have just the more highly trusted, verified VM stack to worry about, and no "cross platform," or no one uses it, because they see it's a dumb idea. In addition, there are tools for making JNI easier. But the reason nobody writes JNI isn't that it's hard, it's that it's stupid. If you need JNI, you probably don't need Java.
Maybe it's just me, but I don't find it that hard anyway.
I can't understand your comment about app server pricing. It sounds like envy that there is no usable free or open source app server for
Bah. Using that macro language to handle dependencies is absolutely absurd. You can say the disorganized mess that grew up around it and in it wasn't C/C++'s fault. I don't think its an accident that there was never at any time in any place a clear and comprehensive API that a C or C++ programmer could use. Let alone missing other kind of nice things like for instance astandardized String class that was actually used in said API. Or language level support for threading. Or what have you.
You have some good points and I always expected there'd be more direct-to-native Java, but as I learned more about how it worked, I began to realize that A) there are advantages, including potential performance advantages, to the VM, and B) the essential features that you want out of Java require something rather like a VM, whether or not you package it hidden in the EXE or separately.
But yes, ultimately, I think the future involves the lower-level platform native tools becoming less insane (and vaguely more "Java-like," although really just more organized and modern generally).
After C/C++, Java ended a long nightmare of preprocessor abuse, ridiculous "APIs" (collections of warring header files with no-vowels function names that were never the same from computer to computer), especially GUI APIs (never failed to amaze me how someone could call Swing "stupid" and then go back to coding Win32 or Motif... Apple guys I can forgive :)... And then there was all the fun of the endless futility of "expecting" programmers to always get their own memory management right. That one really burns me.
;)
C/C++ never took the rap for billions upon billions of dollars in lost productivity because of all the bizarre failure modes of memory allocation failures (hey, there's garbage on the screen... or, hey... it's Tuesday, the full moon is out and the app segfaulted again... coincidence?) or having some clever sixteen year old shove 80k up your 256 byte buffer. You can't tell me wrestling with the garbage collector isn't an improvement on this, because it's ridiculous.
Java of course is within spitting distance of C++ already in one or two benchmarks, but in reality nobody cared either way because you got things in trade that made it a good deal even when it was still quite slow. Not sure what "consistency of the output code" means, but...
You got it right about LAMP. The problems were often that the higher level systems (well, PHP anyway) were great for making websites, but didn't enforce enough rules to be a good idea for projects above a certain size. Still and all, a great many companies in the 90's said "OK, we need 8-way oracle boxes with hot swap CPUs and a 50 disk RAID and Oracle and Weblogic, and... now, what are we going to build exactly?" Most of these places could and should have just used PHP on a few pentiums and saved themselves time and money and headaches. On the other hand, I saw plenty of places coast on a slick of Perl and human blood well past the point where they needed real "enterprise" (hate that word) software development.
It seems like Java was only ever a victim of its own success. No one ever wrote a shitty applet or misused the VM in some way, where the whole language didn't get blamed as a result. Basically, it's another tool in the toolbox, and though it drives C/C++ guys to conniptions, it's the right choice to replace many applications programming tasks right now. Not that I wouldn't throw a party to meet its succeesor.
Unlike many big languages past, Java is probably never going away. No one seems to have realized it yet, but as the VM-first-mover it's the ultimate langauge standard. I bet you people will be porting the Java VM long after we're dead.
This article (and for that matter the writeup) sounds almost like the result of some graduate student AI experiment.
Looks like people are nostalgic for the glory days, when some fictional pseudotechnical concepts no one even understood could echo across boardrooms and bathroom stalls and stir venture capital investments and make you cool at parties.
Is there anything to this, at all, other than taking several unrelated, incremental and entirely unremarkable improvements in user interface and style and putting them in a fancy basket with a bottle of wine and a wedge of cheese?
I hoped we saw the last of that damn hippie-dippy Louis Rosetto school of engineering after the bomb. Powered by bright lights, ignorance and peer pressure.
Very true, although I think if you do the AL piece the way you're supposed to, where you're really forced to formally codify your assumptions about how your application interacts with clients (to the point where you can roll out a highly restrictive ruleset in production), that's actually something I'd call _part_ of good coding and code review. In no way a panacea, but the rigor, the redundancy, can be very beneficial.
I think I get it now. I think many people see those sections and head straight for an appliance like Teros as a "conclusive" way to demonstrate compliance with a lot of 6.5 and a few other ones. But you're right, the AL firewall is not specifically required.
:) Thanks, I learned something.
Damn, I wish I could revise my post.
And section 6.5?
So, just a stateful firewall, eh? What did you do for sections 11.4 and 11.5?
You're absolutely right. Of course, if the providers are smart, they won't let people get away with crippling the system, but time will tell on that... Different places will take it more or less seriously. You never get a magic box you can just plug in and get security for free. It only works when everyone begins to think about the security systems from the get-go. In my experience there is often something to be gained across the board (not just in security) from the simple practice of formally declaring your expectations about traffic patterns (to the point where you could feed those rules into an appliance for enforcement).
Eh? Nice link, but you didn't really read it I guess. I have seen PCI compliance many times which required truly comprehensive standards for IT security, and the use of a certified vendor like Teros, as well as a (quarterly) inspection by a certified inspection service and many other things. Picture an 80-item questionare where every answer has to be yes. And these are orgs with stellar fraud/CB stats.
I don't know what level you are. You may have lesser requirements if you don't have that much volume...
You might want to either do some reading in advance, or be a little more circumspect next time...
The larger point of database security measures notwithstanding, I think the days of the "dumb" application-blind firewall are over.
Most companies that handle credit cards in modest amounts are required by their providers to use application-aware systems like Teros, which inspect every detail of every transaction across the border at the highest levels - providing a redundant check in the form of a policy controlling things like what cookies and querystring values can accompany a request for a particular path, and looking for things like cookies appearing that you didn't set, or form values being submitted that weren't in the HTML form you sent out...
Hmm... Good point.
Hey Diebold, don't let the door hit you in the ass on the way out!
(Not that state regulators which didn't require a voter-verified paper trail up front have qualifications for anything but a prison cell, but hey...)
We thought we would finish this sooner... but we didn't.
Eventually we kind of gave up trying, but we're too nice to just take it off the website?
Who would have thought?
Or... my personal favorite:
"Beta" as a kludge to workaround users who don't read disclaimers and get hopping mad when things don't work. I swear that accounts for a big percentage of the people who do this.
It's too obvious to require a study.
:)
Your university isn't a real business. It _sounds_ the classic case of where that kind of hacking _does_ happen.
I've seen a lot of real businesses use Linux (and Unix and OS's in general) by now. How many? Put it this way: way, way more than were involved in this study.
In an environment where downtime costs real money/goodwill, you work with the vendor on every aspect of your environment, or you don't work with that vendor at all, so those kinds of hacks are never seriously considered. This is so that when something goes wrong, you can blame the vendor and keep your job.
There's a lot of fancy ducking and dodging, none of which changes the facts that:
Lego's invention is very old, and was patented a long time ago.
Patents live only so long. This is for a reason. Granting exclusive monopolies on things forever is not a good idea.
Lego's patent expired, long, long after they had recouped money orders of magnitude beyond what would induce others to attempt to innovate in that industry.
Other people started to make lego-like bricks.
Like a lot of monopolists, Lego became addicted to not having and not suffering competitors. They decided that they wanted to play lawyer games and try to keep others from competing with them rather than follow the law, and pretended that the studs on the bricks that make them work are "trademarked" by them...
The judge basically said, "Look, don't you even try that stunt in here. Your patent expired. The studs on the blocks are a mechanical feature, not a mark. Go away."