Many years ago, I installed Redhat on my Alpha at work. I went on to install some of the basic packages I use daily, but most of them were not available for Alpha in binary form. This is where ports wins big...the same OS on multiple platforms.
I'm a huge NetBSD fan, myself. Go look at how many platforms it runs on and you'll see why this makes sense. As a software developer, I only have to, for the most part, try my application on one system and it's available to all. Sure, I can write something that's big endian specific, or won't run in 64-bit mode, but then each one of those problems can be fixed and portability is restored, in one place.
I've been amazed at how well this has worked out on my multiple NetBSD platforms at home. If it could do the same for multiple operating systems, that would be great for everyone.
Even on a single machine, it gives you a great deal of flexibility. For example, I don't update my pkgsrc and ports trees, I just get them out of AFS on demand from public AFS servers that update them periodically. Now, even if I did have write access to the AFS servers for building, that'd be slow an irresponsible, so I have it build everything in a tmp directory. Don't like where it installs things? Tell it to install third-part packages somewhere else (such as a platform-specific AFS volume). Got a lot of the identical machines? ``make package'' will make a binary package you can install in a platform-specific directory rather than you having to do the same fetches and builds in multiple places.
It's a powerful system, and will hopefully get more people looking at systems other than Linux on a PC. Maybe next time I try Linux on an Alpha, or some other hardware, I won't feel so alienated.
Just because you don't hear about it doesn't mean it's not happening. The BSDs have historically been put into place and have just worked.
I've noticed a lot of Linux users care more about the public opinion of their OS than how well it works for them. I've got at least nine heavily active BSD machines working in my house at all times. All of my corporate mail is filtered through two NetBSD machines. We've got NetBSD IDS machines in various places. NetBSD application servers, web servers, DNS servers. It'd take me a while to make an inventory, but I think we should all do our part to keep you better informed at what people are doing with their computers so you won't feel so bad about making a non-technical choice.
Did you consider that the reason you don't see as much usenet activity for things like NetBSD as you do for things like Linux is that NetBSD is very clearly documented and pretty much always Just Works? That's been the case in my usage, anyway. I've had nearly no trouble with the OS in the six or so years I've been using it (would've been around 1994 or 1995). When I have had a problem, a web search or usenet search would turn up the answer usually. Outside of that, there are the mailing lists. Did you look at those for activity?
Well, anyway. It's alive as long as one person wants to use it. Even if that's just me.
My five-year-old does have an e-mail address, and we have been using it as part of her learn-to-read-better education. I can't wait until some congressman tells me that it's everyone's right to interrupt that process with a constant stream of words from my sponsors (who happen to not be sponsoring the process at all, but are trying to sell my five-year-old hot teen sluts with hair removing toner sticking out of their asses).
I program in *lots* of languages, and every new language I learn teaches me a bit more about programming itself. I encourage everyone I know to learn as many languages as is possible.
The key here is to learn *programming*, not a language. Java has a lot going for it, primarily its large and actually portable codebase and detailed standards. It makes it excellent for actually deploying code, but I don't think it's the best learning language out there. Contrary to what this article would have you believe, it's *not* a pure OO language. They got close to making a very good language, but they left out a few important details. Some of the problems I've noticed include java having native types (very confusing for new java programmers), not having multiple inheritence (causes a lot of code to have to be cut and pasted that would otherwise not be), and a few other inconsistencies I run into periodically that look someone just got too tired to complete the design. Before anyone suggests it's more efficient to have primitive types in the language, consider Eiffel. Not only does every native Eiffel program run faster than the equivelant Java program, in my experience (and that of otheres), a translation of a C program to Eiffel will run as fast or faster than the hand-written C (much like a C program will often run faster than a hand-written assembler program). It makes things much easier on the programmer, as he doesn't have to keep up with all of the exceptions to the rules, for example, you can have an array of ints, but not a Vector of ints. You can grow a Vector, but not an array. It's silly.
If you want to teach OO, pick a good OO language that's easy to learn. Eiffel is a very good learning language. If you want to teach algorithms, use a language that makes it easy to express your algorithms. I used to mock up programs in perl to test algorithms, then use my target language for deployment. I would strongly discourage any new programmers from learning perl too early, though. It's the BASIC of our generation...to be succesful, we need to understand what we're doing, perl tends to figure out what people were trying to do and working with it. The worst programmers I've dealt with were the ones who only knew perl.
C is very unforgiving, but when you're programming in C, you're telling the computer exactly what to do. I think C with a really good environment to tell you what you did wrong would be good. Forget OO and all that stuff. Basic programming and computer skills first, application design and development later. The big problem with C, though, is that nobody understands it.
I guess I don't have the answer to the question, but I believe that learning to program is the important part. The language is just a tool. Really, it sounds a bit like they're arguing whether to teach someone vi or emacs to write their code. No matter what you go with, you're going to learn *something* about programming...and the more you go, the more you're going to learn.
Re:Flaws in the Analysis? (software compatibility)
on
OSX/Win2K Deathmatch
·
· Score: 1
I disagree on your assessment regarding how software compatibility should work. I think this whole concept of ``backwards compatibility through portability'' has been holding us back. Apple is very good at leaping forward and providing an emulation layer. Look at the PPC, when it was launched, it was launched with almost no native software, and I heard (and made) complaints that it was ridiculous that they should make a platform for which there is no native software and have stuff run under a slower emulation.
So what if it runs slower? It runs, and it still runs pretty fast in the grand scheme of things. I'm on a 1999 series powerbook right now, and I can run Netscape with flash, or my older OS 9 version of quicktime to process or play video and it feels just about the same to me. OS X is an advancement that simply couldn't have been made if ``native'' compatibility were a requirement due to the way OS X worked.
Regarding the ability to run a ten-year-old DOS program flawlessly on a Windows 2000 computer, I'm sure you could do the same thing with 100% emulation, say, with a Java applet DOS/PC emulator if someone felt like writing one. I think we can make more progress through emulation (and more thoroughly and easily) than we can by trying to make sure everything works forward and backwards.
Plan9 (and probably some other systems) do not delete data. The preferred way to run Plan9 file servers involves worm media for the storage...at least it used to, hard drives are cheap enough nowadays that you can just write to a big IDE and never delete from it.
Deletes in Plan9 are similar to PostgreSQL's former concept of time travel. Deletes are logical, and, as a user, you can look at any file or directory you have access to at any point in the file or directory's history. See the bind manpage for an excellent example of this.
Yeah, it's off topic, but if you can point out that IBM should sue all OS's, I should be able to point out that all blanket statements are false.:)
Let's not forget squid. There are places out there you can get ACLs for squid for censoring and it does an excellent job of keeping you away from things you don't want to see.
I use it in the corporate environment to keep nasty applications (Real Player) from updating themselves every single minute:
Then you just get something to keep your file up to date, and you've got dynamically filtering censorware.
Not that I'm saying it's the right thing to do, but if this is an attempt to keep Linux distributors from selling their products in Texas, it's a poor one.
Slashdot Mirror
Many years ago, I installed Redhat on my Alpha at work. I went on to install some of the basic packages I use daily, but most of them were not available for Alpha in binary form. This is where ports wins big...the same OS on multiple platforms.
I'm a huge NetBSD fan, myself. Go look at how many platforms it runs on and you'll see why this makes sense. As a software developer, I only have to, for the most part, try my application on one system and it's available to all. Sure, I can write something that's big endian specific, or won't run in 64-bit mode, but then each one of those problems can be fixed and portability is restored, in one place.
I've been amazed at how well this has worked out on my multiple NetBSD platforms at home. If it could do the same for multiple operating systems, that would be great for everyone.
Even on a single machine, it gives you a great deal of flexibility. For example, I don't update my pkgsrc and ports trees, I just get them out of AFS on demand from public AFS servers that update them periodically. Now, even if I did have write access to the AFS servers for building, that'd be slow an irresponsible, so I have it build everything in a tmp directory. Don't like where it installs things? Tell it to install third-part packages somewhere else (such as a platform-specific AFS volume). Got a lot of the identical machines? ``make package'' will make a binary package you can install in a platform-specific directory rather than you having to do the same fetches and builds in multiple places.
It's a powerful system, and will hopefully get more people looking at systems other than Linux on a PC. Maybe next time I try Linux on an Alpha, or some other hardware, I won't feel so alienated.
Just because you don't hear about it doesn't mean it's not happening. The BSDs have historically been put into place and have just worked.
I've noticed a lot of Linux users care more about the public opinion of their OS than how well it works for them. I've got at least nine heavily active BSD machines working in my house at all times. All of my corporate mail is filtered through two NetBSD machines. We've got NetBSD IDS machines in various places. NetBSD application servers, web servers, DNS servers. It'd take me a while to make an inventory, but I think we should all do our part to keep you better informed at what people are doing with their computers so you won't feel so bad about making a non-technical choice.
Did you consider that the reason you don't see as much usenet activity for things like NetBSD as you do for things like Linux is that NetBSD is very clearly documented and pretty much always Just Works? That's been the case in my usage, anyway. I've had nearly no trouble with the OS in the six or so years I've been using it (would've been around 1994 or 1995). When I have had a problem, a web search or usenet search would turn up the answer usually. Outside of that, there are the mailing lists. Did you look at those for activity?
Well, anyway. It's alive as long as one person wants to use it. Even if that's just me.
My five-year-old does have an e-mail address, and we have been using it as part of her learn-to-read-better education. I can't wait until some congressman tells me that it's everyone's right to interrupt that process with a constant stream of words from my sponsors (who happen to not be sponsoring the process at all, but are trying to sell my five-year-old hot teen sluts with hair removing toner sticking out of their asses).
I program in *lots* of languages, and every new language I learn teaches me a bit more about programming itself. I encourage everyone I know to learn as many languages as is possible.
The key here is to learn *programming*, not a language. Java has a lot going for it, primarily its large and actually portable codebase and detailed standards. It makes it excellent for actually deploying code, but I don't think it's the best learning language out there. Contrary to what this article would have you believe, it's *not* a pure OO language. They got close to making a very good language, but they left out a few important details. Some of the problems I've noticed include java having native types (very confusing for new java programmers), not having multiple inheritence (causes a lot of code to have to be cut and pasted that would otherwise not be), and a few other inconsistencies I run into periodically that look someone just got too tired to complete the design. Before anyone suggests it's more efficient to have primitive types in the language, consider Eiffel. Not only does every native Eiffel program run faster than the equivelant Java program, in my experience (and that of otheres), a translation of a C program to Eiffel will run as fast or faster than the hand-written C (much like a C program will often run faster than a hand-written assembler program). It makes things much easier on the programmer, as he doesn't have to keep up with all of the exceptions to the rules, for example, you can have an array of ints, but not a Vector of ints. You can grow a Vector, but not an array. It's silly.
If you want to teach OO, pick a good OO language that's easy to learn. Eiffel is a very good learning language. If you want to teach algorithms, use a language that makes it easy to express your algorithms. I used to mock up programs in perl to test algorithms, then use my target language for deployment. I would strongly discourage any new programmers from learning perl too early, though. It's the BASIC of our generation...to be succesful, we need to understand what we're doing, perl tends to figure out what people were trying to do and working with it. The worst programmers I've dealt with were the ones who only knew perl.
C is very unforgiving, but when you're programming in C, you're telling the computer exactly what to do. I think C with a really good environment to tell you what you did wrong would be good. Forget OO and all that stuff. Basic programming and computer skills first, application design and development later. The big problem with C, though, is that nobody understands it.
I guess I don't have the answer to the question, but I believe that learning to program is the important part. The language is just a tool. Really, it sounds a bit like they're arguing whether to teach someone vi or emacs to write their code. No matter what you go with, you're going to learn *something* about programming...and the more you go, the more you're going to learn.
I disagree on your assessment regarding how software compatibility should work. I think this whole concept of ``backwards compatibility through portability'' has been holding us back. Apple is very good at leaping forward and providing an emulation layer. Look at the PPC, when it was launched, it was launched with almost no native software, and I heard (and made) complaints that it was ridiculous that they should make a platform for which there is no native software and have stuff run under a slower emulation.
So what if it runs slower? It runs, and it still runs pretty fast in the grand scheme of things. I'm on a 1999 series powerbook right now, and I can run Netscape with flash, or my older OS 9 version of quicktime to process or play video and it feels just about the same to me. OS X is an advancement that simply couldn't have been made if ``native'' compatibility were a requirement due to the way OS X worked.
Regarding the ability to run a ten-year-old DOS program flawlessly on a Windows 2000 computer, I'm sure you could do the same thing with 100% emulation, say, with a Java applet DOS/PC emulator if someone felt like writing one. I think we can make more progress through emulation (and more thoroughly and easily) than we can by trying to make sure everything works forward and backwards.
Plan9 (and probably some other systems) do not delete data. The preferred way to run Plan9 file servers involves worm media for the storage...at least it used to, hard drives are cheap enough nowadays that you can just write to a big IDE and never delete from it.
:)
Deletes in Plan9 are similar to PostgreSQL's former concept of time travel. Deletes are logical, and, as a user, you can look at any file or directory you have access to at any point in the file or directory's history. See the bind manpage for an excellent example of this.
Yeah, it's off topic, but if you can point out that IBM should sue all OS's, I should be able to point out that all blanket statements are false.
I use it in the corporate environment to keep nasty applications (Real Player) from updating themselves every single minute:
acl banned_sites dstdomain "/usr/local/squid/etc/banned_domains.txt"
[...]
http_access deny banned_sites
Then you just get something to keep your file up to date, and you've got dynamically filtering censorware.
Not that I'm saying it's the right thing to do, but if this is an attempt to keep Linux distributors from selling their products in Texas, it's a poor one.
--