Any decent software firewall will let you shut down whatever port you like. Perhaps even the built-in Microsoft firewall lets you do that now if you configure it correctly.
Lisp is no more of a "functional language" than Python or Perl.
suitable for scaring off perfectly qualified CS students.
Any CS student that's scared off by Lisp shouldn't be in CS.
Lisp is quirky to a fault: car, cdr, and the different meanings of ` and ' are bad historic anomalies enshrined as The Truth.
Lisp syntax is no more complex than Perl or Bourne shell syntax, languages that lots of people use with no hesitation every day.
I'd just keep strongly functional ones off the list.
I did: there was no Haskell or anything like that. Lisp supports a functional programming style (just like Perl and Python), but it is a procedural language (because its functions can have side-effects).
As it happens, people don't naturally think functionally, people think procedurally.
As it happens, people don't naturally think object-oriented, or in UML diagrams, or in terms of recursion, or in terms of pointers. Education is about teaching people new ways of thinking. It is not about letting people go on in ruts and just having them memorize a bunch of Java APIs.
Computers don't process things functionally, they process things procedurally. Lisp is a deep shock for most people and can very effectively scare new students away.
It is exactly that kind of misguided thinking that makes it important to teach functional programming concepts early on. Languages like Lisp, Python, and Scheme give instructors the option of exposing their students to many programming styles early on. Languages like Java, Pascal, and C are just deeply deficient for teaching because they are on-paradigm languages.
That is exactly what the license says, and what that means is exactly that you cannot implement Java without violating Sun's intellectual property: if you implement it, you have to implement all of it before you can release any of it (which is pretty much an impossibility for open source) and even then, Sun is the final arbiter whether your software is, in fact, compliant. That is not an open standard, it is one of the most restrictive standards imaginable. Every single non-Sun implementation of the Java platform is in violation of this license right now and can be shut down by Sun at any time.
If this kind of standard came from Microsoft, would you consider it "open" if Microsoft said "but we are the final arbiters of whether your implementation is compliant? I don't think so. So, why do you take that bullshit from Sun? The fact that Sun misrepresents this kind of proprietary standard as "open" only shows that, in addition to not being open, they are also being deceptive. That's not the kind of company I want to do business with or I want to help "beat Microsoft".
Microsoft Japan is suspected of attaching improper restrictive conditions when signing software deals with Japanese personal computer manufacturers, such as requiring that Japanese companies allow infringement of their patents."
A deal "allowing infringement of one's patent" is more commonly referred to as a "patent license". I don't see anything improper about that
The problem is the monopoly itself, not the specific conditions that Microsoft can impose using that monopoly. Forcing manufacturers to license their patents is no more or less injurious than forcing consumers to pay $200 for Windows XP Home.
Until a couple of years ago, it mattered to me that Java was closed source and that the Java specification itself was closed. (Yes, the Java specification is not open--you can't just implement it without violating Sun's intellectual property.)
Now, I just don't care anymore. Java has fulfilled its function: it has made garbage collection and runtime safety acceptable among commercial programmers. The Java language and libraries themselves are nothing to write home about and never were. Java could have become a good, general-purpose language and a good, general-purpose platform, but it never really fulfilled its promise. It's become a mediocre specialty language mostly for some kinds of server-side hacking. Open sourcing it or opening the spec would only prolong the agony.
People should move forward and widen their intellectual horizons again. Look at languages other than Java and get over this illusion that we will ever have a single language in which everything will be done on every platform.
Wrong, any program is large enough for a beginner to be caught out by a language that doesn't hold their hand.
Languages like Scheme actually "catch out" every error that Java catches out, and they have far better type checking than languages like C. Furthermore, educational environments for languages like Scheme give students a lot more handholding during both development and debugging than any of the existing Java environments.
That's not a conspiracy theory at all. It is what patent portfolios and their cross-licensing have always done: kept most players without deep pockets out of the market. It's just that there exists now an additional competitor without deep pockets but a lot of significance: OSS.
Sure, I agree: the syntax is a bit of a hurdle with Scheme, and the fact that there is no redundancy in its nesting invites errors. But there are good introductory programming environments for Scheme that pretty eliminate that problem. Furthermore, understanding Scheme syntax is in itself a useful learning experience.
Java syntax may be a little more "robust", but it has its own problems, in that it contains a lot of ad-hoc syntactic constructs; and unlike Scheme, with Java programmers really have to learn all that syntax before they can become productive.
In terms of syntax, I think languages like Python, Ruby, and some forms of Basic strike a good middle ground for education, having "mainstream" syntax on the one hand, and an interactive dynamic programming environment on the other. I don't think they are necessarily better introductory programming languages than Scheme, but they fit better into a curriculum where students will eventually have to deal with languages like Java, C#, and C anyway.
On the contrary, that makes it an excellent language to learn with because you don't suffer from the "shooting yourself in the foot" syndrome.
In intro CS classes, programmers shouldn't write applications that are large enough for that to be a concern.
This is the exact reason why CS classes in nearly every high school while I was that age taught programming in Pascal...the compiler will catch the programmer assigning an int to a string then testing it like a boolean.
The reason high schools used Pascal was because it was a fashion to do so, just like it's a fashion to use Java now.
What have CS courses switched to? Java. Why? First off, Javadoc. You head over to Javas resource page and you have an easily indexed hierarchy of all the base Java classes.
Java's automatically generated documentation is about as un-didactic and scary to a beginner as any kind of documentation could be. And even for experienced programmers, that kind of automatically ground out documentation junk is perhaps better than nothing, but that's about the best one can say about it.
Secondly, Java reads like English. Sadly, System.out.println is probably the most useful and complicated statement a beginner will learn, but look for any Java source and you can practically read, in English, what the code is doing.
It is highly doubtful whether "reading like English" is a desirable feature in a programming language, even if Java did "read like English". That's because Java certainly doesn't behave like English, so why should it give the impression that it "reads like" it? Of course, in reality, it's hard to see what is so English-like about constructs like "if(...) {... } {... }".
Yes, you are right that Microsoft, so far hasn't done that. They haven't needed to, since they have been able to dominate the industry through other means. So, Microsoft is not guilty of any special kind of abuse of the patent system, they simply abuse it in the same way every large company abuses the patent system.
There are plenty of folks suing them over frivolous patents.
And how is creating more "frivolous patents" going to help with that?
Perhaps their latest rash of applications are more defensive than offensive.
There is no such thing as a "defensive patent": sooner or later, a company has to assert, or at least threaten to assert, the claims in one of their patents if it is going to do them any good. And that makes the patent offensive.
Sometimes people think that a patent is used "defensively" in order to establish priority. That's nonsense--a simple disclosure does the same thing and is nearly free. Even Microsoft wouldn't waste $50k-$100k on that.
In fact, most likely, Microsoft is filing patents in order to allow them to get a portfolio for cross-licensing. And that, in itself, is anti-competitive because it ends up keeping people out of the market. It just happens that most of the big companies are in on that kind of anti-competitive behavior.
Sorry, but you should learn something else. Really, if you don't take the time to learn programming (hey, be thankful it's Java and not LISP;-) you should do something else.
No, he shouldn't be "thankful". Quite to the contrary. LISP is an interactive, dynamically typed language, which makes it great for introductory CS teaching. So are Python, Basic, Logo, Ruby, and many others.
Java is a statically typed, compiled language with enormous libraries and messy, complicated development environments. That makes it a poor choice for an introductory course.
I think it's extremely important to at least understand the basics of "how is software built". And learning a programming language is actually a lot easier than learning a real language, and you can learn both if just sit down and practice, gawddamnit !
For someone who already knows programming, that's true. But these students are supposed to learn programming.
Your argument actually supports what I'm saying: you should teach students programming in a language that is well-suited to the task of teaching and that doesn't burden beginners with irrelevant and complex features. You should also teach in a language that doesn't narrow the view students get of CS; sadly, Java is a one paradigm language, and a very limited paradigm at that. Once they have learned programming in a teaching language, as you say yourself, learning another programming language is easy.
You could study applied math, electrical engineering, computer engineering, cognitive science, human-computer interaction, psychology, etc. All of them involve high-tech and aspects of computer science, but they won't make you do lots of programming initially. However, when you actually work in them, it will be hard for you to avoid programming anyway, and you will be less prepared.
If you hate your intro CS course, chances are that the intro CS course is just poorly taught. And Java itself is a pretty questionable choice as an intro CS language in my opinion: it's tedious, it's sluggish, and has enormously complex libraries. It also is based on a very narrow view of what programming is and how people should build abstractions.
I'm not sure what you can do about that. Switching majors within your university is one choice. Switching universities might be another if you think that that kind of teaching is common at your university. Or you may just sit through this and hope that it improves. It depends on how much you are dedicated to CS. Your university may also treat this as a kind of hazing ritual, to weed out people who just aren't all that interested in CS after all.
One think you can do is have a look at the intro CS lectures at other universities and see how they compare (MIT's 6.001 is a good course to look at); maybe that would help you make up your mind whether you just dislike your course or whether you dislike the field.
DVDs have a fairly complicated structure involving multiple files and multiple file types and containing numerous indexes and references. If you mirror them with vobcopy, you can then point some of the free DVD players at the ripped directory structure and get the menus and everything else. So, if you export the mirrored directories via some network file system, you should be able to play them over the network. It is possible that one or the other network file system has some glitch that causes problems (e.g., unexpected latencies for certain operations), but then just try another one or fiddle with the parameters for that file system.
Intel has always defined the technology, and AMD has always been the follower.
For many years, Intel was way, way behind other chip makers in both technology and performance and it didn't hurt them financially. Even today, it's clear that they are technologically at best equal to much smaller competitors. Size gives them a market advantage and the ability to force standards through--good or bad--but size rarely gives companies a technology advantage.
If BSD were as popular as Linux, then it might be in serious trouble right now because SCO could claim that all their contributions to it, in fact, remained proprietary. In contrast, the fact that Linux is covered by the GPL gives Linux a strong defense against SCO's claims, given that SCO itself has distributed it.
And the issue over BSD code ownership is not resolved: SCO is still making claims about it. If BSD ever becomes important enough, they may go to court over it.
Rarely the level of features and performances that people are used too...
Well, duh, if people don't use it, then it doesn't get more mature.
Find me something with the level of functionality of bind and that scale, i'm interrested...
You can run the "bind" codebase itself securely by running it with a safer C runtime. But what it comes down to is that people like you just don't give a damn about security: you just reject any alternative because any alternative means some level of temporary inconvenience for you.
Fine. But people like you just shouldn't tell other people that something like this AMD hack is going to fix everybody's security problems--it just won't. Our computer infrastructure is insecure because people like you choose to keep it insecure (that's not to say that you yourself have any say in the matter--just that your attitude is very common).
Geekier-than-thou Steve Mann already demonstrated this as video orbits, and there has been plenty of other work on the same subject. Most of the research actually looks at general mosaicing, not just documents. Use with cell phones so far has simply been limited by the limited availability of cell phones with video capability, not by any conceptual problems.
Start by rewriting bind in the safe language of your choice... [...] Until you have something to show, STFU...
For just about every major server component (DNS, SMTP, HTTP, etc.), you can already get numerous implementations in a variety of safe languages. Those are pretty much immune to buffer overflows and many of the other security problems that regularly plague C/C++-based server code. So, there is plenty of stuff to show, it's just that people like you are too ignorant to use it and that people like you behave like jerks when someone suggests they do.
Maybe this will change now that Microsoft is pushing for languages and runtimes like C#/CLR that, in fact, do support runtime safety from the ground up while still being flexible enough to allow system programming. You can expect much of Microsoft's system software and servers to be rewritten in C#/CLR and most of their buffer overflow problems going away. Hopefully, Linux will follow the same path.
To have the code jump at some unintended place, like that $HOME environment variable where you conveniently put your shellcode. What happens when the section where environment variables are is not executable as it should be? Program segfaults instead of the machine being owned...
No, you just have the return pointer point at some place in the executable that already creates a shell; it wouldn't jump to the $HOME variable.
It'd be nice to prevent buffer overflows in the first place, but errors do happen and having a single line of defense is a really bad idea if it is ever breached...
Right now, people have no defense, and this AMD hack doesn't create much of a defense either. Neither do your code reviews or library changes.
The good attitude is do the most you can to prevent buffer overflows (by any means necessary, code reviews, replacing unsafe APIs like OpenBSD [openbsd.org] did replacing all occurences of strcpy(), strcat(3) and sprintf(3) by safer counterparts) and having tight memory protection. Add to that some privilege separation work, chroot(2) anything chrootable and you have way better sleep...
No, that's a lousy attitude, because it doesn't address the underlying problem: the problem that C is severely broken when it comes to fault detection. You are on a boat with a million little holes and plugging them one by one. That just won't work, it will only sink you more slowly.
For anything that needs to be secure, use a language that has reasonable runtime safety. After that, you can still do code reviews and replace "unsafe APIs" if you like. That is, use a language that doesn't have a million little holes. Maybe it still has one or two holes, but those are much easier to plug by hand.
And then what? Program oversteps its bounds and is terminated?
Or it recovers more locally, like "sorry, this SMTP connection will be terminated because it has a string buffer overflow". The server itself will go on working.
Granted, you've prevented a possible buffer overflow and exploit, but the program is still severely broken.
Not at all. It is perfectly legitimate for programs to rely on language-supplied bounds checks to guard against attacks or unusual conditions and it is easy to write exception handling code that will recover from such conditions reliably.
The problem is that people write buggy code. Buggy code won't work right no matter how many protection mechanisms you build into the environment.
No, there is nothing "buggy" about relying on built-in protection mechanisms and throwing a low-level exception under unexpected conditions. Your idea that programmers have to check every single piece of data manually comes from C, where you don't have a choice. But languages are supposed to make programming easier.
Marking pages as executable/non-executable is old, and it's not the way to deal with buffer overflows. Many buffer overflow exploits, in fact, only modify data (like the saved PC pointer).
The correct way of dealing with buffer overflow problems is to make them not happen in the first place. That means that all pointers need to have bounds associated with them. Unfortunately, both the C mindset and some design quirks of the C programming language make that a little harder than it should be for UNIX/Linux and C-based systems.
The real problem is ultimately the use of C, and the real solution is not to use a new CPU or add instructions, but to use a language without C's quirks. In terms of performance, C's pointer semantics only hurt anyway.
It's not about defining XML, but rather developing cool government apps that small countries need to provide basic functions...and get some help from "western" countries in doing it.
But they are defining XML standards and getting far more involved in the software business than I think it makes sense for them.
The small countries that are the target of such projects will NEVER be able to afford the proprietary solutions that are being suggested! If they DO get any "free" MS or IBM stuff from the deal, that's simply taxpayer money down the toilet to another US multinational...
I agree with that. But I suspect presenting small countries with ready-made solutions on a silver platter isn't going to help in the long run; instead, the UN needs to create awareness of open source and encourage its creation around the world, in particular in those poor/small countries. Unless they actually develop a culture of OSS development, anything else is likely to be futile. And if small countries get a culture of OSS development, they will create and exchange the necessary OSS solutions among themselves.
What the UN could do is finance and distribute lots of PCs with Linux pre-installed. That's a simple, well-defined task the UN can handle.
shouldn't get involved in the definition of XML standards at all. After all, we already have several excellent international, neutral standards bodies that worry about this sort of thing.
Re:completely underwhelmed by Subversion...
on
Subversion 1.0 Released
·
· Score: 1, Flamebait
Arch suffers from the common GNU problem of assuming that a Unix system with a Unixy filesystem is the only environment worth paying attention to, and despite what Richard Stallman might think, that _is_ a problem.
No, you got it backwards. Writing open source software as if it has to run on both Windows and Linux is a problem. Commercial software vendors aren't dragged down by that kind of cross-platform boat anchor--they just write for Windows.
Trying to achieve cross-platform availability is corrupting major open source projects; for example, Mozilla and KDE are both as inefficient, bloated, and flickering because their toolkits try to make some sort of compromise between Windows and X11.
Open source simply won't be fully competitive this way; it's amazing it's as good as it is given this millstone.
Arch seems not only less useful but also depressingly backward-looking in philosophy.
The "depressingly backwards looking philosophy" is the philosophy that tries to bring us to a lowest common denominator of all operating systems.
and despite what Richard Stallman might think, that _is_ a problem.
It's not just Stallman that's saying it. I'm tired of missed releases and poor functionality due to attempts by developers to accomodate Windows. Windows has enough software; don't waste time on adding more to it for free.
Slashdot Mirror
Any decent software firewall will let you shut down whatever port you like. Perhaps even the built-in Microsoft firewall lets you do that now if you configure it correctly.
Lisp is a quirky functional language
Lisp is no more of a "functional language" than Python or Perl.
suitable for scaring off perfectly qualified CS students.
Any CS student that's scared off by Lisp shouldn't be in CS.
Lisp is quirky to a fault: car, cdr, and the different meanings of ` and ' are bad historic anomalies enshrined as The Truth.
Lisp syntax is no more complex than Perl or Bourne shell syntax, languages that lots of people use with no hesitation every day.
I'd just keep strongly functional ones off the list.
I did: there was no Haskell or anything like that. Lisp supports a functional programming style (just like Perl and Python), but it is a procedural language (because its functions can have side-effects).
As it happens, people don't naturally think functionally, people think procedurally.
As it happens, people don't naturally think object-oriented, or in UML diagrams, or in terms of recursion, or in terms of pointers. Education is about teaching people new ways of thinking. It is not about letting people go on in ruts and just having them memorize a bunch of Java APIs.
Computers don't process things functionally, they process things procedurally. Lisp is a deep shock for most people and can very effectively scare new students away.
It is exactly that kind of misguided thinking that makes it important to teach functional programming concepts early on. Languages like Lisp, Python, and Scheme give instructors the option of exposing their students to many programming styles early on. Languages like Java, Pascal, and C are just deeply deficient for teaching because they are on-paradigm languages.
That is exactly what the license says, and what that means is exactly that you cannot implement Java without violating Sun's intellectual property: if you implement it, you have to implement all of it before you can release any of it (which is pretty much an impossibility for open source) and even then, Sun is the final arbiter whether your software is, in fact, compliant. That is not an open standard, it is one of the most restrictive standards imaginable. Every single non-Sun implementation of the Java platform is in violation of this license right now and can be shut down by Sun at any time.
If this kind of standard came from Microsoft, would you consider it "open" if Microsoft said "but we are the final arbiters of whether your implementation is compliant? I don't think so. So, why do you take that bullshit from Sun? The fact that Sun misrepresents this kind of proprietary standard as "open" only shows that, in addition to not being open, they are also being deceptive. That's not the kind of company I want to do business with or I want to help "beat Microsoft".
Microsoft Japan is suspected of attaching improper restrictive conditions when signing software deals with Japanese personal computer manufacturers, such as requiring that Japanese companies allow infringement of their patents."
A deal "allowing infringement of one's patent" is more commonly referred to as a "patent license". I don't see anything improper about that
The problem is the monopoly itself, not the specific conditions that Microsoft can impose using that monopoly. Forcing manufacturers to license their patents is no more or less injurious than forcing consumers to pay $200 for Windows XP Home.
Until a couple of years ago, it mattered to me that Java was closed source and that the Java specification itself was closed. (Yes, the Java specification is not open--you can't just implement it without violating Sun's intellectual property.)
Now, I just don't care anymore. Java has fulfilled its function: it has made garbage collection and runtime safety acceptable among commercial programmers. The Java language and libraries themselves are nothing to write home about and never were. Java could have become a good, general-purpose language and a good, general-purpose platform, but it never really fulfilled its promise. It's become a mediocre specialty language mostly for some kinds of server-side hacking. Open sourcing it or opening the spec would only prolong the agony.
People should move forward and widen their intellectual horizons again. Look at languages other than Java and get over this illusion that we will ever have a single language in which everything will be done on every platform.
Wrong, any program is large enough for a beginner to be caught out by a language that doesn't hold their hand.
Languages like Scheme actually "catch out" every error that Java catches out, and they have far better type checking than languages like C. Furthermore, educational environments for languages like Scheme give students a lot more handholding during both development and debugging than any of the existing Java environments.
I teach introductory level C courses
Maybe you shouldn't, then.
Then again, you could read hundreds of man pages and figure it out yourself ;)
Personally, I find that a lot more exciting compared to hearing someone drone on for months about Java and their silly ideas about "good" OO design.
That's not a conspiracy theory at all. It is what patent portfolios and their cross-licensing have always done: kept most players without deep pockets out of the market. It's just that there exists now an additional competitor without deep pockets but a lot of significance: OSS.
Sure, I agree: the syntax is a bit of a hurdle with Scheme, and the fact that there is no redundancy in its nesting invites errors. But there are good introductory programming environments for Scheme that pretty eliminate that problem. Furthermore, understanding Scheme syntax is in itself a useful learning experience.
Java syntax may be a little more "robust", but it has its own problems, in that it contains a lot of ad-hoc syntactic constructs; and unlike Scheme, with Java programmers really have to learn all that syntax before they can become productive.
In terms of syntax, I think languages like Python, Ruby, and some forms of Basic strike a good middle ground for education, having "mainstream" syntax on the one hand, and an interactive dynamic programming environment on the other. I don't think they are necessarily better introductory programming languages than Scheme, but they fit better into a curriculum where students will eventually have to deal with languages like Java, C#, and C anyway.
On the contrary, that makes it an excellent language to learn with because you don't suffer from the "shooting yourself in the foot" syndrome.
... } { ... }".
In intro CS classes, programmers shouldn't write applications that are large enough for that to be a concern.
This is the exact reason why CS classes in nearly every high school while I was that age taught programming in Pascal...the compiler will catch the programmer assigning an int to a string then testing it like a boolean.
The reason high schools used Pascal was because it was a fashion to do so, just like it's a fashion to use Java now.
What have CS courses switched to? Java. Why? First off, Javadoc. You head over to Javas resource page and you have an easily indexed hierarchy of all the base Java classes.
Java's automatically generated documentation is about as un-didactic and scary to a beginner as any kind of documentation could be. And even for experienced programmers, that kind of automatically ground out documentation junk is perhaps better than nothing, but that's about the best one can say about it.
Secondly, Java reads like English. Sadly, System.out.println is probably the most useful and complicated statement a beginner will learn, but look for any Java source and you can practically read, in English, what the code is doing.
It is highly doubtful whether "reading like English" is a desirable feature in a programming language, even if Java did "read like English". That's because Java certainly doesn't behave like English, so why should it give the impression that it "reads like" it? Of course, in reality, it's hard to see what is so English-like about constructs like "if(...) {
They haven't. They don't do business that way.
Yes, you are right that Microsoft, so far hasn't done that. They haven't needed to, since they have been able to dominate the industry through other means. So, Microsoft is not guilty of any special kind of abuse of the patent system, they simply abuse it in the same way every large company abuses the patent system.
There are plenty of folks suing them over frivolous patents.
And how is creating more "frivolous patents" going to help with that?
Perhaps their latest rash of applications are more defensive than offensive.
There is no such thing as a "defensive patent": sooner or later, a company has to assert, or at least threaten to assert, the claims in one of their patents if it is going to do them any good. And that makes the patent offensive.
Sometimes people think that a patent is used "defensively" in order to establish priority. That's nonsense--a simple disclosure does the same thing and is nearly free. Even Microsoft wouldn't waste $50k-$100k on that.
In fact, most likely, Microsoft is filing patents in order to allow them to get a portfolio for cross-licensing. And that, in itself, is anti-competitive because it ends up keeping people out of the market. It just happens that most of the big companies are in on that kind of anti-competitive behavior.
Sorry, but you should learn something else. Really, if you don't take the time to learn programming (hey, be thankful it's Java and not LISP ;-) you should do something else.
No, he shouldn't be "thankful". Quite to the contrary. LISP is an interactive, dynamically typed language, which makes it great for introductory CS teaching. So are Python, Basic, Logo, Ruby, and many others.
Java is a statically typed, compiled language with enormous libraries and messy, complicated development environments. That makes it a poor choice for an introductory course.
I think it's extremely important to at least understand the basics of "how is software built". And learning a programming language is actually a lot easier than learning a real language, and you can learn both if just sit down and practice, gawddamnit !
For someone who already knows programming, that's true. But these students are supposed to learn programming.
Your argument actually supports what I'm saying: you should teach students programming in a language that is well-suited to the task of teaching and that doesn't burden beginners with irrelevant and complex features. You should also teach in a language that doesn't narrow the view students get of CS; sadly, Java is a one paradigm language, and a very limited paradigm at that. Once they have learned programming in a teaching language, as you say yourself, learning another programming language is easy.
You could study applied math, electrical engineering, computer engineering, cognitive science, human-computer interaction, psychology, etc. All of them involve high-tech and aspects of computer science, but they won't make you do lots of programming initially. However, when you actually work in them, it will be hard for you to avoid programming anyway, and you will be less prepared.
If you hate your intro CS course, chances are that the intro CS course is just poorly taught. And Java itself is a pretty questionable choice as an intro CS language in my opinion: it's tedious, it's sluggish, and has enormously complex libraries. It also is based on a very narrow view of what programming is and how people should build abstractions.
I'm not sure what you can do about that. Switching majors within your university is one choice. Switching universities might be another if you think that that kind of teaching is common at your university. Or you may just sit through this and hope that it improves. It depends on how much you are dedicated to CS. Your university may also treat this as a kind of hazing ritual, to weed out people who just aren't all that interested in CS after all.
One think you can do is have a look at the intro CS lectures at other universities and see how they compare (MIT's 6.001 is a good course to look at); maybe that would help you make up your mind whether you just dislike your course or whether you dislike the field.
DVDs have a fairly complicated structure involving multiple files and multiple file types and containing numerous indexes and references. If you mirror them with vobcopy, you can then point some of the free DVD players at the ripped directory structure and get the menus and everything else. So, if you export the mirrored directories via some network file system, you should be able to play them over the network. It is possible that one or the other network file system has some glitch that causes problems (e.g., unexpected latencies for certain operations), but then just try another one or fiddle with the parameters for that file system.
Intel has always defined the technology, and AMD has always been the follower.
For many years, Intel was way, way behind other chip makers in both technology and performance and it didn't hurt them financially. Even today, it's clear that they are technologically at best equal to much smaller competitors. Size gives them a market advantage and the ability to force standards through--good or bad--but size rarely gives companies a technology advantage.
If BSD were as popular as Linux, then it might be in serious trouble right now because SCO could claim that all their contributions to it, in fact, remained proprietary. In contrast, the fact that Linux is covered by the GPL gives Linux a strong defense against SCO's claims, given that SCO itself has distributed it.
And the issue over BSD code ownership is not resolved: SCO is still making claims about it. If BSD ever becomes important enough, they may go to court over it.
Rarely the level of features and performances that people are used too...
Well, duh, if people don't use it, then it doesn't get more mature.
Find me something with the level of functionality of bind and that scale, i'm interrested...
You can run the "bind" codebase itself securely by running it with a safer C runtime. But what it comes down to is that people like you just don't give a damn about security: you just reject any alternative because any alternative means some level of temporary inconvenience for you.
Fine. But people like you just shouldn't tell other people that something like this AMD hack is going to fix everybody's security problems--it just won't. Our computer infrastructure is insecure because people like you choose to keep it insecure (that's not to say that you yourself have any say in the matter--just that your attitude is very common).
Geekier-than-thou Steve Mann already demonstrated this as video orbits, and there has been plenty of other work on the same subject. Most of the research actually looks at general mosaicing, not just documents. Use with cell phones so far has simply been limited by the limited availability of cell phones with video capability, not by any conceptual problems.
Start by rewriting bind in the safe language of your choice... [...] Until you have something to show, STFU...
For just about every major server component (DNS, SMTP, HTTP, etc.), you can already get numerous implementations in a variety of safe languages. Those are pretty much immune to buffer overflows and many of the other security problems that regularly plague C/C++-based server code. So, there is plenty of stuff to show, it's just that people like you are too ignorant to use it and that people like you behave like jerks when someone suggests they do.
Maybe this will change now that Microsoft is pushing for languages and runtimes like C#/CLR that, in fact, do support runtime safety from the ground up while still being flexible enough to allow system programming. You can expect much of Microsoft's system software and servers to be rewritten in C#/CLR and most of their buffer overflow problems going away. Hopefully, Linux will follow the same path.
To have the code jump at some unintended place, like that $HOME environment variable where you conveniently put your shellcode. What happens when the section where environment variables are is not executable as it should be? Program segfaults instead of the machine being owned...
No, you just have the return pointer point at some place in the executable that already creates a shell; it wouldn't jump to the $HOME variable.
It'd be nice to prevent buffer overflows in the first place, but errors do happen and having a single line of defense is a really bad idea if it is ever breached...
Right now, people have no defense, and this AMD hack doesn't create much of a defense either. Neither do your code reviews or library changes.
The good attitude is do the most you can to prevent buffer overflows (by any means necessary, code reviews, replacing unsafe APIs like OpenBSD [openbsd.org] did replacing all occurences of strcpy(), strcat(3) and sprintf(3) by safer counterparts) and having tight memory protection. Add to that some privilege separation work, chroot(2) anything chrootable and you have way better sleep...
No, that's a lousy attitude, because it doesn't address the underlying problem: the problem that C is severely broken when it comes to fault detection. You are on a boat with a million little holes and plugging them one by one. That just won't work, it will only sink you more slowly.
For anything that needs to be secure, use a language that has reasonable runtime safety. After that, you can still do code reviews and replace "unsafe APIs" if you like. That is, use a language that doesn't have a million little holes. Maybe it still has one or two holes, but those are much easier to plug by hand.
And then what? Program oversteps its bounds and is terminated?
Or it recovers more locally, like "sorry, this SMTP connection will be terminated because it has a string buffer overflow". The server itself will go on working.
Granted, you've prevented a possible buffer overflow and exploit, but the program is still severely broken.
Not at all. It is perfectly legitimate for programs to rely on language-supplied bounds checks to guard against attacks or unusual conditions and it is easy to write exception handling code that will recover from such conditions reliably.
The problem is that people write buggy code. Buggy code won't work right no matter how many protection mechanisms you build into the environment.
No, there is nothing "buggy" about relying on built-in protection mechanisms and throwing a low-level exception under unexpected conditions. Your idea that programmers have to check every single piece of data manually comes from C, where you don't have a choice. But languages are supposed to make programming easier.
Marking pages as executable/non-executable is old, and it's not the way to deal with buffer overflows. Many buffer overflow exploits, in fact, only modify data (like the saved PC pointer).
The correct way of dealing with buffer overflow problems is to make them not happen in the first place. That means that all pointers need to have bounds associated with them. Unfortunately, both the C mindset and some design quirks of the C programming language make that a little harder than it should be for UNIX/Linux and C-based systems.
The real problem is ultimately the use of C, and the real solution is not to use a new CPU or add instructions, but to use a language without C's quirks. In terms of performance, C's pointer semantics only hurt anyway.
It's not about defining XML, but rather developing cool government apps that small countries need to provide basic functions...and get some help from "western" countries in doing it.
But they are defining XML standards and getting far more involved in the software business than I think it makes sense for them.
The small countries that are the target of such projects will NEVER be able to afford the proprietary solutions that are being suggested! If they DO get any "free" MS or IBM stuff from the deal, that's simply taxpayer money down the toilet to another US multinational...
I agree with that. But I suspect presenting small countries with ready-made solutions on a silver platter isn't going to help in the long run; instead, the UN needs to create awareness of open source and encourage its creation around the world, in particular in those poor/small countries. Unless they actually develop a culture of OSS development, anything else is likely to be futile. And if small countries get a culture of OSS development, they will create and exchange the necessary OSS solutions among themselves.
What the UN could do is finance and distribute lots of PCs with Linux pre-installed. That's a simple, well-defined task the UN can handle.
shouldn't get involved in the definition of XML standards at all. After all, we already have several excellent international, neutral standards bodies that worry about this sort of thing.
Arch suffers from the common GNU problem of assuming that a Unix system with a Unixy filesystem is the only environment worth paying attention to, and despite what Richard Stallman might think, that _is_ a problem.
No, you got it backwards. Writing open source software as if it has to run on both Windows and Linux is a problem. Commercial software vendors aren't dragged down by that kind of cross-platform boat anchor--they just write for Windows.
Trying to achieve cross-platform availability is corrupting major open source projects; for example, Mozilla and KDE are both as inefficient, bloated, and flickering because their toolkits try to make some sort of compromise between Windows and X11.
Open source simply won't be fully competitive this way; it's amazing it's as good as it is given this millstone.
Arch seems not only less useful but also depressingly backward-looking in philosophy.
The "depressingly backwards looking philosophy" is the philosophy that tries to bring us to a lowest common denominator of all operating systems.
and despite what Richard Stallman might think, that _is_ a problem.
It's not just Stallman that's saying it. I'm tired of missed releases and poor functionality due to attempts by developers to accomodate Windows. Windows has enough software; don't waste time on adding more to it for free.