In the next few months, you'll be deluged with advice, not just here on slashdot, but from all kinds of people on campus, from upper classpeople to profs to counselors to people who never even went to college but still like to give advice. The best advice I can give you (this comming from a senior at Michigan State) is to decide for yourself what the best decisions are. If you follow all of random pieces of advice ("you *must* get this prof!!), all of the rules of thumb (x hours of studying per y credit hours), and even all of the rules (no drinking, he he) you'll really shortchange yourself out of the true college experience, which is finding out what works for *you*. It'll take some time, and probably at least one semester that you'll have to write off as far as grades are concerned, but not only will you be a better college student, you'll be a better person as a result.
You forget about the BSDi code influx...
on
Is BSD Dying?
·
· Score: 2
One thing people seem to forget when discussing the future of the Linux/BSD debate is that, although Linux 2.4 has made some great strides and has almost reached parity with FreeBSD in terms of performance, as I write this oodles of code from BSDi (most notably some unreal SMP enhancements) is making its way into the FreeBSD codebase. So, even if Linux 2.6 leapfrogs FreeBS 4.X, just remember that some of the best multitasking/multithreading code is comming to FreeBSD. Considering how fast BSDi is, if some of that magic dust rubs off on FreeBSD, Linux will be hard pressed to compete.
I've been running an OpenBSD-based firewall on a K6-200 for this school year, and I couldn't recompile the kernel or any userland binaries until I dropped the memory form 64MB to 32MB. So, if it's the >32MB bug that's affecting you, installing OpenBSD might not help.
Last I checked, at least some Imac models were fanless. You might be able to use one of these with an external HD to get the results you want. ust getting an Imac (or a similarly prebuilt fanless computer) would probably be the easiest route to go (assuming the Mac had all the audio software you need - considering how much Macs are used in the audio industry, it might!).
The Net, among other media, zaps information that was once available only via "enclave" institutions -- schools, libraries, publishing companies, churches, universities -- to whomever cares to see it.
I must admit, I have to take issue with the above statement. Not that the Internet isn't making the information referred to above available - it's just that it's always been available. Schools, libraries, and universities have always been open sources of information. At MSU, where I go to school, all libraries are open to the public, and all classes are similarly open (though you have to pay if you want credit). Churches, too, are quite open when it comes to disseminating information (sometimes to a fault). The only institution left on the list are publishing companies, and the only way in which they differ is that they charge. The point I'm (finally) trying to make is that an overwhelming amount of the world's information, especially scientific information, has already been freely and openly available for a very, very long time. The only new wrinkle the Internet has added is that it makes the information available to every lazy Joe Sixpack who is too apathetic to go to a library. That's my $.02, take it or leave it.
Without being explicitly pro or con Microsoft, a few things Microsoft could do to make its bug-squashing chores easier within the context of a closed-source operation: 1. Run a bugtraq-style mailing list. Even without the source, there are a lot of people with extensive enough knowledge of Windows OS internals to provide at least some outside insight as to why a particular bug might be occurring. 2. Make a really kick-a#! debugger readily and freely available in the tradition of gdb. Make things like core dumps and other Unix diagnostic niceties standard, to allow people the ability to pull something useful out of the rubble for a postmortem. Obviously, within a closed-source paradigm, some method would be needed to ensure that only Microsoft programmers could dissassemble the cores; encryption, maybe? (and yes, I know there's a joke in there somewhere about a user's disk filling up with core dumps within five seconds, but I'm leaving it alone!) 3. Two words: architechture independence. While I have no hard facts to back this up, I would imagine that, because Microsoft is concentrating on a single hardware architechture, quite a bit of assembley code is sneaking its way in. Assembley code is good for speed, but (although there will be doubtlessly much debate about this) the fact remains that the more architechture-independent code is in a product, the more stable it is. For further proof, look at early OSs (such as MSDOS 1.0) that are coded significantly in assembley, and something like BSD Unix, which is about 80% architechture independent - the only assmbley routines are device I/O, memory mapping, and other such things. If Microsoft went to an architechture-independent approach, it could make its debugging job a lot easier.
I know that many people here will probably flame me for giving honest suggestions to Microsoft, but politics aside I think that if Microsoft were to take up the practices I outlined above, along with similar practices common in the Unix world, it would make all our lives a lot easier. After all, Microsoft is going to be here for quite a while, and the less pain that existence inflicts on us, the better.
Before the initial frenzy hits, may I just remind everyone that this is a *very* new technology. Just because it has a GPL license doesn't mean it won't stink. Hopefully, of course, it won't, and if there are shortcomings I hope that the collaborative effors of open source programmers can overcome it. However, I know that there will be a couple of hundred/. posters that will just see the words "major corporation" and "GPL" and automatically think that it's the best thing since sliced bread. Maybe HP is on to something, but until I see what this is really capable of, the GPL won't mean much.
The scene... I have left for vacation. I set up crontab entries in a control computer to activate the robot periodically while I'm gone. Little did I know, I had left computer parts scattered around on the floor. Come on guys. Sounds like this item would be a good idea in theory for a geek present. However, considering how many geeks (myself included) have a habit of leaving computers in various states of disassembley all over the place, somehow I doubt it would be a good idea to turn a non-intelligent vacuuming robot loose in a geek's room.
Just to clarify, yes, I do mean the delay is bad (the last sentence of my post should spell this out). XF86 4 will no doubt be a great thing, and I personally intend to upgrade as soon as it comes out (whenever that may be).
Although many readers probably don't realize it, this is actually really bad news for the Linux gaming community. For those who are unfamiliar with the design specifications of Xfree86 4.0, one of the major planned innovations is tightly integrated 3D accelleration. Not only will this significantly improve performance and stability, it will also make it easier to make a given video card compatible, this increasing Unix's (yes, XFree86 IS at least somewhat cross-platform!) viability as a gaming platform. The sooner good, integrated, compatible 3D support comes to Unix, the better off Unix gaming will be.
One VERY important thing to consider is how the clustering technology is implemented in a given solution. For example, Mosix does not require any rewrites to your code, except maybe making the program fork off more often so that the processes can become more distributed. Paralell Virtual Machine (PVM), which is one of the most popular methods of implementing Beowulf clusters, however, is a code library that must be integrated into each program you want to run on the cluster. So, depending on your (or your users) programming knowledge, you should be careful about what clustering architecture you use.
As OpenBSD has been a lesser-known OS for a while, I am writing this post to tell any newcomers what it is all about. While to many this may seem like just another software release, anyone who has watched cryptography and security in general and OpenBSD in particular knows that this will have major significance throughout the industry. It may not be immediately apparant, or even obvious, but it will be important for the follwing reasons: 1. With the recent anti-cryptography crackdowns by the US government (see the article below this one on the investigation of William Simpson), having a complete system of VERY strong cryptography coming from outside our national borders, such as OpenBSD, will significantly weaken our government's efforts to stop cryptography. 2. OpenBSD is apparantly the only major OS that truly follows the saying, "Security is a process, not a product." Personally (and I know there will be much debate on this, possibly even flames), I believe that everyone from the Linux contributors to Sun (makers of Solaris) to, of course, Microsoft, could learn from the example of the OpenBSD team. For those of you unfamiliar with OpenBSD, here are a few examples of how the emphasis in this OS is almost entirely on security: A. Line-by-line security audit of *everything* that goes on the CD. B. Strong cryptography is built in on the most basic system level. C. All aspects of the default setup have undergone rigorous security testing. OpenBSD is, to the best of my knowledge, the only OS that can legitimately claim to be secure right out of the box. All of these factors combined have set a standard that the rest of the industry has yet to meet. Eventually, security will be seen as something not to be expected, but demanded in a product, and the OpenBSD philosophy will serve as a model for this shift. 3. Because many security flaws (such as potential buffer overflows) can cause security-unrelated crashes, the line-by-line audit also resulted in remarkable stability beyond just the security. I think we can all think of a certain software company that could learn from this example. 4. The overall view of the OpenBSD team that security as not just something that happens over time and numerous patches, but rather something to get right the first time, must be adopted by the rest of the industry as soon as possible. Anything less will hold back the advance of the Internet unacceptably. I hope that this has helped some newcomers to the OpenBSD world understand the underlying philosophy of this wonderful OS.
Looking at what has happened to the software industry as whole, it seems to be remarkably similar to a concept in genetics (and mathematics) known as "regression towards the mean." In this concept, a given community with a large degree of diversity (such as the set of companies in the software industry) will, in successive generations (or years), slowly move from a diverse set of subjects to a less diverse set where most companies hover near the mean in respect to various measurements. In the context of the software industry, an anomalous mutation (such as a hypergreedy company like Microsoft) skewed the mean, causing companies in the future to move towards the new way of business. Then, the widespread adoption of Open Source philosophies, (and maybe even the antitrust suit!) created a second anomoly that is balancing the mean away from the region Microsoft had skewed it to. So, to make a VERY (sorry!) long post short, do we as a movement want the mean to keep moving towards pure open source philosophies, or do we want the mean that future efforts will regress to to be closer to benevolent yet profitable companies like Red Hat and MandrakeSoft?
Currently, the statistics (as any/. reader knows) show that Apache, especially Apache on Linux, is currently winning the server war. However, if the recent benchmarks from Mindcraft are any indication, Linux may start to lose market share simply due to lack of competitiveness in the performance area. Obviously, Apache (being largely OS-independent) will almost certainly survive the the "server war." However, unless very significant improvements occurr in Linux performance, and soon, the Linux-Apache combo may be replaced in popularity by an Apache-(fill-in-the-blank-with-your-favorite-*nix) combo. Does anyone else see this as a possibility?
I know that some people won't like it when I say anything that could be constured as negative towards Transmeta in general, but the idea of a reconfigurable processor is not at all new. Field Programmable Gate Arrays (FPGAs) are 'blank' microprocessors that can be configured and reconfigured almost like and EEPROM. They are used in, among other things, prototypes and first-run products, because if bugs emerge instead of having to pull out a chip they can merely reconfigure it. Granted, these chips are, to date, used primarily in small-scale embedded products, although MIT has a project (I believe called the Oxygen project) that will scale up the concept considerably. However, Transmeta does seem to be the first to take the concept to this extreme (at least, that's what the rumors tell us).
What some of these posts have but many do not is a proper context for the definition. Most of us here seem to agree that the definition of an operating system is something like a kernel, a shell, some services and libraries, or basically whatever bare minimum it takes to start a program. Now, in the context of DOS, it may be just 3 files (io.sys and msdos.sys, and command.com). For Linux, it may be the kernel, a few kernel modules, a shell, and some init scripts to get the ball rolling. However, in the context of Win2k, all that code may well, in this context at least, fall under the definition of the bare minimum it takes. Therefore, if you stop looking at the definition of an OS as a static definition, but rather one that changes with context (as all definitions of all words do), it will become clear that all of that code does indeed fall under the definition of an OS
Slashdot Mirror
In the next few months, you'll be deluged with advice, not just here on slashdot, but from all kinds of people on campus, from upper classpeople to profs to counselors to people who never even went to college but still like to give advice. The best advice I can give you (this comming from a senior at Michigan State) is to decide for yourself what the best decisions are. If you follow all of random pieces of advice ("you *must* get this prof!!), all of the rules of thumb (x hours of studying per y credit hours), and even all of the rules (no drinking, he he) you'll really shortchange yourself out of the true college experience, which is finding out what works for *you*. It'll take some time, and probably at least one semester that you'll have to write off as far as grades are concerned, but not only will you be a better college student, you'll be a better person as a result.
One thing people seem to forget when discussing the future of the Linux/BSD debate is that, although Linux 2.4 has made some great strides and has almost reached parity with FreeBSD in terms of performance, as I write this oodles of code from BSDi (most notably some unreal SMP enhancements) is making its way into the FreeBSD codebase. So, even if Linux 2.6 leapfrogs FreeBS 4.X, just remember that some of the best multitasking/multithreading code is comming to FreeBSD. Considering how fast BSDi is, if some of that magic dust rubs off on FreeBSD, Linux will be hard pressed to compete.
I've been running an OpenBSD-based firewall on a K6-200 for this school year, and I couldn't recompile the kernel or any userland binaries until I dropped the memory form 64MB to 32MB. So, if it's the >32MB bug that's affecting you, installing OpenBSD might not help.
Last I checked, at least some Imac models were fanless. You might be able to use one of these with an external HD to get the results you want. ust getting an Imac (or a similarly prebuilt fanless computer) would probably be the easiest route to go (assuming the Mac had all the audio software you need - considering how much Macs are used in the audio industry, it might!).
I must admit, I have to take issue with the above statement. Not that the Internet isn't making the information referred to above available - it's just that it's always been available. Schools, libraries, and universities have always been open sources of information. At MSU, where I go to school, all libraries are open to the public, and all classes are similarly open (though you have to pay if you want credit). Churches, too, are quite open when it comes to disseminating information (sometimes to a fault). The only institution left on the list are publishing companies, and the only way in which they differ is that they charge. The point I'm (finally) trying to make is that an overwhelming amount of the world's information, especially scientific information, has already been freely and openly available for a very, very long time. The only new wrinkle the Internet has added is that it makes the information available to every lazy Joe Sixpack who is too apathetic to go to a library. That's my $.02, take it or leave it.
Without being explicitly pro or con Microsoft, a few things Microsoft could do to make its bug-squashing chores easier within the context of a closed-source operation:
1. Run a bugtraq-style mailing list. Even without the source, there are a lot of people with extensive enough knowledge of Windows OS internals to provide at least some outside insight as to why a particular bug might be occurring.
2. Make a really kick-a#! debugger readily and freely available in the tradition of gdb. Make things like core dumps and other Unix diagnostic niceties standard, to allow people the ability to pull something useful out of the rubble for a postmortem. Obviously, within a closed-source paradigm, some method would be needed to ensure that only Microsoft programmers could dissassemble the cores; encryption, maybe? (and yes, I know there's a joke in there somewhere about a user's disk filling up with core dumps within five seconds, but I'm leaving it alone!)
3. Two words: architechture independence. While I have no hard facts to back this up, I would imagine that, because Microsoft is concentrating on a single hardware architechture, quite a bit of assembley code is sneaking its way in. Assembley code is good for speed, but (although there will be doubtlessly much debate about this) the fact remains that the more architechture-independent code is in a product, the more stable it is. For further proof, look at early OSs (such as MSDOS 1.0) that are coded significantly in assembley, and something like BSD Unix, which is about 80% architechture independent - the only assmbley routines are device I/O, memory mapping, and other such things. If Microsoft went to an architechture-independent approach, it could make its debugging job a lot easier.
I know that many people here will probably flame me for giving honest suggestions to Microsoft, but politics aside I think that if Microsoft were to take up the practices I outlined above, along with similar practices common in the Unix world, it would make all our lives a lot easier. After all, Microsoft is going to be here for quite a while, and the less pain that existence inflicts on us, the better.
Before the initial frenzy hits, may I just remind everyone that this is a *very* new technology. Just because it has a GPL license doesn't mean it won't stink. Hopefully, of course, it won't, and if there are shortcomings I hope that the collaborative effors of open source programmers can overcome it. However, I know that there will be a couple of hundred /. posters that will just see the words "major corporation" and "GPL" and automatically think that it's the best thing since sliced bread. Maybe HP is on to something, but until I see what this is really capable of, the GPL won't mean much.
The scene... I have left for vacation. I set up crontab entries in a control computer to activate the robot periodically while I'm gone. Little did I know, I had left computer parts scattered around on the floor. Come on guys. Sounds like this item would be a good idea in theory for a geek present. However, considering how many geeks (myself included) have a habit of leaving computers in various states of disassembley all over the place, somehow I doubt it would be a good idea to turn a non-intelligent vacuuming robot loose in a geek's room.
Just to clarify, yes, I do mean the delay is bad (the last sentence of my post should spell this out). XF86 4 will no doubt be a great thing, and I personally intend to upgrade as soon as it comes out (whenever that may be).
Although many readers probably don't realize it, this is actually really bad news for the Linux gaming community. For those who are unfamiliar with the design specifications of Xfree86 4.0, one of the major planned innovations is tightly integrated 3D accelleration. Not only will this significantly improve performance and stability, it will also make it easier to make a given video card compatible, this increasing Unix's (yes, XFree86 IS at least somewhat cross-platform!) viability as a gaming platform. The sooner good, integrated, compatible 3D support comes to Unix, the better off Unix gaming will be.
One VERY important thing to consider is how the clustering technology is implemented in a given solution. For example, Mosix does not require any rewrites to your code, except maybe making the program fork off more often so that the processes can become more distributed. Paralell Virtual Machine (PVM), which is one of the most popular methods of implementing Beowulf clusters, however, is a code library that must be integrated into each program you want to run on the cluster. So, depending on your (or your users) programming knowledge, you should be careful about what clustering architecture you use.
As OpenBSD has been a lesser-known OS for a while, I am writing this post to tell any newcomers what it is all about. While to many this may seem like just another software release, anyone who has watched cryptography and security in general and OpenBSD in particular knows that this will have major significance throughout the industry. It may not be immediately apparant, or even obvious, but it will be important for the follwing reasons: 1. With the recent anti-cryptography crackdowns by the US government (see the article below this one on the investigation of William Simpson), having a complete system of VERY strong cryptography coming from outside our national borders, such as OpenBSD, will significantly weaken our government's efforts to stop cryptography. 2. OpenBSD is apparantly the only major OS that truly follows the saying, "Security is a process, not a product." Personally (and I know there will be much debate on this, possibly even flames), I believe that everyone from the Linux contributors to Sun (makers of Solaris) to, of course, Microsoft, could learn from the example of the OpenBSD team. For those of you unfamiliar with OpenBSD, here are a few examples of how the emphasis in this OS is almost entirely on security: A. Line-by-line security audit of *everything* that goes on the CD. B. Strong cryptography is built in on the most basic system level. C. All aspects of the default setup have undergone rigorous security testing. OpenBSD is, to the best of my knowledge, the only OS that can legitimately claim to be secure right out of the box. All of these factors combined have set a standard that the rest of the industry has yet to meet. Eventually, security will be seen as something not to be expected, but demanded in a product, and the OpenBSD philosophy will serve as a model for this shift. 3. Because many security flaws (such as potential buffer overflows) can cause security-unrelated crashes, the line-by-line audit also resulted in remarkable stability beyond just the security. I think we can all think of a certain software company that could learn from this example. 4. The overall view of the OpenBSD team that security as not just something that happens over time and numerous patches, but rather something to get right the first time, must be adopted by the rest of the industry as soon as possible. Anything less will hold back the advance of the Internet unacceptably. I hope that this has helped some newcomers to the OpenBSD world understand the underlying philosophy of this wonderful OS.
Looking at what has happened to the software industry as whole, it seems to be remarkably similar to a concept in genetics (and mathematics) known as "regression towards the mean." In this concept, a given community with a large degree of diversity (such as the set of companies in the software industry) will, in successive generations (or years), slowly move from a diverse set of subjects to a less diverse set where most companies hover near the mean in respect to various measurements. In the context of the software industry, an anomalous mutation (such as a hypergreedy company like Microsoft) skewed the mean, causing companies in the future to move towards the new way of business. Then, the widespread adoption of Open Source philosophies, (and maybe even the antitrust suit!) created a second anomoly that is balancing the mean away from the region Microsoft had skewed it to. So, to make a VERY (sorry!) long post short, do we as a movement want the mean to keep moving towards pure open source philosophies, or do we want the mean that future efforts will regress to to be closer to benevolent yet profitable companies like Red Hat and MandrakeSoft?
Currently, the statistics (as any /. reader knows) show that Apache, especially Apache on Linux, is currently winning the server war. However, if the recent benchmarks from Mindcraft are any indication, Linux may start to lose market share simply due to lack of competitiveness in the performance area. Obviously, Apache (being largely OS-independent) will almost certainly survive the the "server war." However, unless very significant improvements occurr in Linux performance, and soon, the Linux-Apache combo may be replaced in popularity by an Apache-(fill-in-the-blank-with-your-favorite-*nix) combo. Does anyone else see this as a possibility?
I know that some people won't like it when I say anything that could be constured as negative towards Transmeta in general, but the idea of a reconfigurable processor is not at all new. Field Programmable Gate Arrays (FPGAs) are 'blank' microprocessors that can be configured and reconfigured almost like and EEPROM. They are used in, among other things, prototypes and first-run products, because if bugs emerge instead of having to pull out a chip they can merely reconfigure it. Granted, these chips are, to date, used primarily in small-scale embedded products, although MIT has a project (I believe called the Oxygen project) that will scale up the concept considerably. However, Transmeta does seem to be the first to take the concept to this extreme (at least, that's what the rumors tell us).
What some of these posts have but many do not is a proper context for the definition. Most of us here seem to agree that the definition of an operating system is something like a kernel, a shell, some services and libraries, or basically whatever bare minimum it takes to start a program. Now, in the context of DOS, it may be just 3 files (io.sys and msdos.sys, and command.com). For Linux, it may be the kernel, a few kernel modules, a shell, and some init scripts to get the ball rolling. However, in the context of Win2k, all that code may well, in this context at least, fall under the definition of the bare minimum it takes. Therefore, if you stop looking at the definition of an OS as a static definition, but rather one that changes with context (as all definitions of all words do), it will become clear that all of that code does indeed fall under the definition of an OS