``The problem is that 'installware' doesn't have the same negative feeling that 'spyware' and 'adware' have. I personally would recommend re-defining the term 'shovelware' to apply to those programs that you install, and which then proceed to shovel more and more crap programs onto your computer.''
I see things differently. I think it is good that "installware" does not carry the same negative feeling that "spyware" and "adware" have, because it is not as bad as them. Sure, shoving software they didn't ask for on your users is rude, but there is an important distinction between shoving legitimate, useful software that way (which is what Apple does here) and shoving malware on your users (which is what installware is infamous for).
Let's keep "installware" as the general, neutral term for software that tries to install (through forcing, stealth, deception, etc.) software that the user didn't ask for. (Regardless of whether the software being pushed that way is something the user is happy with.)
I'd also like to coin "bundleware" for software distributions that contain a lot of unnecessary (and possibly unwanted) goodies. E.g. Windows drivers that are distributed as an archive with a couple hundred KB for the driver, and tens of megabytes of software, ads, installers, and whatnot that isn't needed for the driver to function. Or Apple's distribution of gcc, which comes with the whole of Xcode in one elephantine download.
``The problem is that they have used "software update" to install a *new* piece of software.''
For everybody's information, Apple have done the same on OS X for as long as I can remember. I don't care for iTunes, Quicktime, and a bunch of other software from Apple. So on my OS X installs, I don't have these. Yet, the Software Update tool keeps giving me "updates" for these components. Selected to install by default, too.
So there is nothing really new here. Apple has been doing this for years. I am happy to see that people are upset about it, though, because I think it's wrong. Me, I never cared enough to so much as complain about it, because I only rarely used OS X anyway.
``Yes, it sucks that backup copies are collateral damage in this battle. But you tell me a better method for us to guarantee that no wholesale bootlegging will occur, and I'll take it to my superiors.''
Does the DRM stop wholesale bootlegging from occurring?
``I used to be pretty judgmental of pop music. But, shit, somebody has to write it. Somebody has to perform it. Somebody has to slave for hours for the final mix. Is the sum of all that talent worthless just because we think we're better than that?''
It's not (at least for me) about being "better than that". It's about what comes out of that process, and if you like it. A lot of pop music just isn't my cup of tea. A lot of the music that I listen to isn't most people's cup of tea - else it would be pop music. I don't think either music is better than the other; there's just what I love, what I like, what I don't like, and what I can't stand. That's not a judgment about how good it is, just about how well it goes with me (which depends on my mood, too).
``Less irreverently... You can't argue facts with people who base their stance on dogma. They have no factual basis to disprove, and no matter how convincing or simple your argument, they can always respond "god did it".''
Exactly. And this is exactly where the difference between science and religion is. In religion, you have to believe, because the dogma (holy book, priest, whatever) says it is so. To believe otherwise would be heresy.
In science, you don't have to believe. In fact, it is good if you doubt. This is how theories get disproven when they are false. Since we eliminate the theories we know to be false, the ones we have left explain the world as well as we know how to. We have faith in the process, not in the dogma.
``The difference is when a Linux update goes haywire, the user is blamed.''
By some. Others might blame it on the system. Yet others may give the user advice on how to do better. Some may ask the user exactly what steps they performed and what exactly went wrong. The problem can then be investigated, which will result in one of (1) nothing (2) the user getting told they shouldn't have done it that way, but rather..., (3) the software getting fixed,(4) both (2) and (3). Last but not least, the user might do the investigation himself, up to and including fixing any software flaws.
All this will happen out in the open.
By contrast, with Microsoft, (1) development and issue resolution happens mostly behind closed doors, (2) users pay for and use Microsoft software because they want it to Just Work, (3) if it doesn't do what you want, you are powerless, and (4) updates _frequently_ break things that were working before.
So, first of all, the expectations are different. Believe it or not, most Microsoft users _expect_ things to Just Work. When they don't, there is outrage. Secondly, you don't get to see how these issues are dealt with. So all you get to see is the outrage at Microsoft.
Ah, and let's not forget: bashing Microsoft is fashionable. It's not just on Slashdot anymore.
1. It requires very high pressures (120 GPa) 2. It's only "room temperature" if you keep your room at 7 K (which is a bit unrealistic...)
On cooling, a typical metallic behavior of the resistance was observed and eventually becoming superconducting (SC) at Tc {approx} 7 K (Fig. 2B). Upon further compression, the sample became completely opaque at 76 GPa, and Tc increased, with pressure up to 17.5 K at 96 GPa and 17 K at 120 GPa (Fig. 2C). At higher pressures, Tc decreases to 8.8 K at 165 GPa and is then likely to increase again to 11.3 K at 192 GPa (Fig. 2C). The behavior of Tc between 90 GPa and 120 GPa is suggestive that higher values of critical temperature of superconductivity may be possible. However, uncontrollable change of pressure during sample loading (20) prohibited us from studying this regime in detail.
In my opinion, the whole machinery of logic programming languages can and should be implemented in terms of a general purpose language. Because what logic programming languages really boil down to (correct me if I'm wrong here) is one or a bunch of solving strategies for logic problems, which they are fed as input. That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library". And the advantage to this is that it is easy to mix your general purpose language with your special purpose language, so you have the power of the former and the convenience of the latter.
One classic example of this is implementing "Prolog" in Lisp. I wrote Prolog in quotes, because what is usually implemented is a language with Lisp syntax and a small subset of the features of Prolog. But still, it's the sort of thing I mean.
``He also said that the target customer (Windows PDA users) wouldn't want to buy an EEE PC because it had Linux on it.''
He's probably right about that one. I know enough people who won't touch Linux unless it's forced on them. Usually because of some imagined defect of Linux's, but the reason doesn't really matter. If it's new and it's with Windows, they'll love it. If it has Linux, they will stay as far away from it as they can.
``No one wants the Microsoft solution where applications need to be certified to run.''
Actually, I do want that solution, and I've advocated it before. What is important, though, is that you can choose your own trust providers (so that the control is not all in a single entity's hands).
Interestingly, this is pretty much what things like apt-get give you. Provided you only install software through apt-get, you get to choose your trust providers (by adding repositories to sources.list), and you can then only install software that has been approved by them.
It works for me. I have about 20000 packages to choose from. They cover my needs. All of them are free software, and none of the ones I have installed have displayed malicious behavior. Did I mention that apt-get also graciously handles dependencies, and makes keeping the system up to date really easy and quick?
And fun. But I also think you can't usufully _design_ your own language without knowing a bunch of different programming paradigms, language constructs, syntaxes, and their strenghts and weaknesses.
I remember I started writing my own programming language when the only programming language I knew was BASIC. Sure enough, it worked around some of the shortcomings I perceived in BASIC. For example, the syntax was more consistent. However, for the most part, it was very much like BASIC. And it used the most ridiculous algorithms and data structures, because BASIC had never taught me to do those right.
Now I know a host of other programming languages, paradigms, syntaxes, language constructs, and data structures. And yet again, I am designing and implementing a programming language. But, this time, it is going to combine the strenghts of various languages into one language, hopefully better than each of the languages its inspired by. And it has some new ideas, too; things that I think no language I know does as well as it could be done.
Oh, and I'm not going to put all my variables in one large string, which then has to be searched on each variable access. Which is what I did in my first programming language implementation. So please. Don't make the mistake I made and think that, since you know one language (and Java and C# are pretty much the same), you know it all.
I've taken a course on this in university. The tools I remember did basically an exhaustive search of all states in your program, and verified that there were no deadlocks and the properties you specified hold in every state.
Needless to say, this is very memory consuming, and can take a long time. So what you really get to verify is simple models, not your actual application with all its different variables. Also, the tools didn't grok Real World programming languages, so you had to write your model in a language other than the one you would eventually write your application in.
In the end, the impression I got is that formal verification is great, but the tools we used don't tell you _anything_ about the application you write, because that's not the code you ran the verification on.
I know that's just the tools we used in that course, but how do you do it? Which tools do you use, and how do they work?
In fact, I know all of these languages (although Haskell far less than most other languages I know), and I have a hard time wrapping my head around these "patterns".
Anything you want to program ought to be simple.
If there is some commonly occuring functionality (which I guess is what you have "patterns" for, so that you have a guide for implementing that functionality), you factor that functionality out into a function or macro.
After that, programming with it is simple.
You don't have to go and re-implement the pattern every time you need it; you just reuse the implementation you wrote before.
Unless, of course, your programming language does not allow you to write that implementation; usually because it lacks macros or first-class functions.
``I hate to say it but this specialization programming and time spent with other people's frameworks and libraries seems to make me more valuable in my own realm.''
Why would you hate to say that? It's the simple truth. Learning more Java and.NET, and more Java and.NET frameworks is obviously going to make you a more valuable Java and.NET programmer.
``You're right, it's a good idea for me to pick up Ruby (or whatever I'm supposed to learn next) because Java is not going to be around forever.''
Since you already know Lisp, I don't think Ruby is going to teach you a lot. Although, of all the programming languages I know, Ruby is the one that offers the least resistance, in that it allows me to simply do what I want to do. But I think its main advantages over Lisp are just that some idioms are slightly less verbose in Ruby (e.g. blocks vs. lambda, a[1] = 42 vs (setf (aref a 1) 42)) and that it ships with libraries for many modern times needs, such as TCP/IP and XML (whereas, with Lisp, these are, at best, not standardized).
``But honestly, I feel a lot of people around me could stop re-inventing the wheel week after week at work and just take a couple days to tweak someone else's solution to work. ''
And that is exactly why I resent Java. The whole culture, from the initial language design up to the latest and greatest framework, is full of reinventing the wheel and, often enough, touting the reinvention as a Great New Thing. Just imagine what could have been accomplished if all the effort that has gone into Java, the standard library, the build tools, etc. etc. had been used to improve an existing language and set of libraries, build tools, etc. And if all the effort that has gone in building yet another build tool, XML library, GUI library, or whatever, because the previous one wasn't good enough, had gone into existing systems, too. And if people looked at the strengths and weaknesses of existing solutions more, so that they would have avoided going through the "make mistakes, fix mistakes, end up with the same thing that somebody else already made before, but incompatible" cycle.
Of course, sometimes it's good to start over. You can't build a solid house on weak foundations. It's not even bad to have multiple languages, build tools, XML libraries, and whatnot. Competition among them will keep everybody motivated to improve their favorite. Just look at Java and.NET:.NET is basically Java with some of Java's mistakes fixed, and now Java and.NET are both innovating like crazy to be better than the other. Suddenly, we have generics, proper type systems, multiple languages on the same VM, etc.
I would recommend Scheme. Not because I recommend you program in it, but because it will change the way you think about programming and programming languages, especially if you also read Structure and Interpretation of Computer Programs (affectionately known as SICP).
Scheme is a small programming language, so you can learn it relatively quickly. This allows you time to read some of the literature about Scheme. And SICP. This will give you insight in the design of programming languages, and how features (like loops, class systems, etc.) can be implemented in terms of simpler constructs, given the right primitives and powerful enough abstractions.
And, in the end, it's the primitives and abstractions that matter. Given the right primitives and abstractions, you can mold your programming language to be anything you want. Scheme, and other languages in the larger Lisp family, are very good at this. That's probably why they are still around, despite tracing their roots back to the 1950s. Other languages are not so good at it, and you will end up writing lots of boilerplate and repetitive code if you program in them.
I could go on and on and list all the insights Scheme has provided me with, but I'd say you go see for yourself. SICP is a good place to start, because it starts at the basics (so you don't need to know Scheme before you start), but gets up to speed really quickly (so you won't get bored). You could also try my Scheme tutorial.
Note that all this is about the 5th revision of Scheme (known as R5RS). R5RS lacks many primitives that would make it useful for Real World applications (just to name one thing, there is nothing about networking). Many implementations of Scheme (and there are many) provide various such primitives - but that's not the point here. The point is about the fundamentals of programming.
As a final remark, if you are used to Java's "everything is part of a class" curfew, Scheme will provide a refreshing change of perspective. R5RS doesn't even have classes. Instead, the focus is on procedures. So you will be decomposing your system in terms of what it does, more than in terms of what real, imaginary, or "forced on you by the programming language" objects it acts on. In my experience, this leads to many small functions, each doing a simple thing, which can then be composed to build your system - or perhaps a very different system that happens to re-use part of the functionality. Unlike Java's classes, each containing a bunch of method, each of which contains gobs of repetitive code...try to adapt _that_ to do something similar, but slightly different. Again, it's all about primitives and abstractions.
``At least in holland a lot of ISP's are happy to advertise with 'download music fast' without having any music service whatsoever. Copyright infringement is one major reason to get one of the more expensive subscriptions, if everyone just went with the cheapest most minimal subscription, you know the one that is plenty for email, the web, gaming etc etc, then ISP's will really feel it in their revenue.''
Also, downloading music and movies (but not software, unless otherwise specified, e.g. in the case of open source) is legal in the Netherlands and many othe EU countries (perhaps all).
IANAL, but I have read the relevant sections of Dutch copyright law. Downloading something from the Internet constitutes making a copy for personal use. This is allowed for all material that comes on media (e.g. music on a CD, where the CD is the medium and the copyrighted work is the music on the CD) except for software. The idea is that file sharing is equivalent to lending your CD to a friend, who then makes a copy for his own use. This is explicitly allowed.
Interestingly, playing a DRMed song or movie that you bought and paid for using an unlicensed player constitutes a circumvention of technical measures and is a criminal offense. Yay DMCA^H^H^H^H^H EUCD.
``When you have that Intel chip that needs a fan that sounds like the Swamp Boat from the WaterBoy movie with Adam Sandler. ''
I have an idea! Maybe the people who care about hd noise _don't_ have Intel chips that need a fan that sounds like the Swamp Boat from the WaterBoy movie with Adam Sandler!
This is not about wear, as far as I know. The flash cards work fine. It's just that Linux starts giving I/O errors after some time. Reboot the system and all is fine again. I think there is a software limit somewhere.
I don't have experiences with actual flash drives, but I tried running my Linux system off flash cards. It was horrible. The system used an USB flash card reader (or two, probably), a 1 GB card for the root partition, and an 8 GB card for/home. Both of these were pretty high speed MMC cards.
I had expected the system to be snappy, because I mostly perform many reads on small files. Flash memory has low seek times, right? Well, the system was noticeably slower running from flash than it had been running from harddisk.
But that wasn't the worst. It was usable. The real problem is that the system would lock up after about two to three days. More flash card usage means it locked up sooner. Apparently, there is a limit on the number of writes (or maybe reads, too) you can do in one of the subsystems (USB, mass storage, maybe somewhere else). After that limit is reached, every flash card access failed with an I/O error, and the system would be dead soon enough.
I asked around for help, but didn't find any pointers, much less a solution to the problem. I reverted back to using harddisks.
While I had a good laugh at the article, I think the really real reason people use Linux is even more obvious. Or, much rather, it is obvious that there isn't _one_ such reason. Different people use Linux for different reasons.
I started with Linux out of curiosity. I suppose that goes in the fun department. Nowadays, I use Linux because it is the most efficient: with Debian, I spend very little time on maintenance, and the system keeps working. No other system I have used has come close to Debian in the low-maintenance department. Yet other people use Linux because they think it's cool. Some people use Linux because their boss tells them to. Or because it comes with the system. Or because they can relatively easily customive it to run on whatever outlandish hardware they have. Or because it has already been so customized. I know someone who uses Linux because benchmarks have shown him that, of all OSes, Linux most efficiently takes advantage of his multi-core hardware. Finally, some people use Linux because they think it is in the public domain and they can do whatever they want with it.
Slashdot Mirror
``The problem is that 'installware' doesn't have the same negative feeling that 'spyware' and 'adware' have. I personally would recommend re-defining the term 'shovelware' to apply to those programs that you install, and which then proceed to shovel more and more crap programs onto your computer.''
I see things differently. I think it is good that "installware" does not carry the same negative feeling that "spyware" and "adware" have, because it is not as bad as them. Sure, shoving software they didn't ask for on your users is rude, but there is an important distinction between shoving legitimate, useful software that way (which is what Apple does here) and shoving malware on your users (which is what installware is infamous for).
Let's keep "installware" as the general, neutral term for software that tries to install (through forcing, stealth, deception, etc.) software that the user didn't ask for. (Regardless of whether the software being pushed that way is something the user is happy with.)
I'd also like to coin "bundleware" for software distributions that contain a lot of unnecessary (and possibly unwanted) goodies. E.g. Windows drivers that are distributed as an archive with a couple hundred KB for the driver, and tens of megabytes of software, ads, installers, and whatnot that isn't needed for the driver to function. Or Apple's distribution of gcc, which comes with the whole of Xcode in one elephantine download.
``The problem is that they have used "software update" to install a *new* piece of software.''
For everybody's information, Apple have done the same on OS X for as long as I can remember. I don't care for iTunes, Quicktime, and a bunch of other software from Apple. So on my OS X installs, I don't have these. Yet, the Software Update tool keeps giving me "updates" for these components. Selected to install by default, too.
So there is nothing really new here. Apple has been doing this for years. I am happy to see that people are upset about it, though, because I think it's wrong. Me, I never cared enough to so much as complain about it, because I only rarely used OS X anyway.
``Yes, it sucks that backup copies are collateral damage in this battle. But you tell me a better method for us to guarantee that no wholesale bootlegging will occur, and I'll take it to my superiors.''
Does the DRM stop wholesale bootlegging from occurring?
``I used to be pretty judgmental of pop music. But, shit, somebody has to write it. Somebody has to perform it. Somebody has to slave for hours for the final mix. Is the sum of all that talent worthless just because we think we're better than that?''
It's not (at least for me) about being "better than that". It's about what comes out of that process, and if you like it. A lot of pop music just isn't my cup of tea. A lot of the music that I listen to isn't most people's cup of tea - else it would be pop music. I don't think either music is better than the other; there's just what I love, what I like, what I don't like, and what I can't stand. That's not a judgment about how good it is, just about how well it goes with me (which depends on my mood, too).
``Pretty much any part of someone's body can supposedly signify something.''
Unlike in the USA, where only your penis size matters.
``Less irreverently... You can't argue facts with people who base their stance on dogma. They have no factual basis to disprove, and no matter how convincing or simple your argument, they can always respond "god did it".''
Exactly. And this is exactly where the difference between science and religion is. In religion, you have to believe, because the dogma (holy book, priest, whatever) says it is so. To believe otherwise would be heresy.
In science, you don't have to believe. In fact, it is good if you doubt. This is how theories get disproven when they are false. Since we eliminate the theories we know to be false, the ones we have left explain the world as well as we know how to. We have faith in the process, not in the dogma.
``The difference is when a Linux update goes haywire, the user is blamed.''
..., (3) the software getting fixed,(4) both (2) and (3). Last but not least, the user might do the investigation himself, up to and including fixing any software flaws.
By some. Others might blame it on the system. Yet others may give the user advice on how to do better. Some may ask the user exactly what steps they performed and what exactly went wrong. The problem can then be investigated, which will result in one of (1) nothing (2) the user getting told they shouldn't have done it that way, but rather
All this will happen out in the open.
By contrast, with Microsoft, (1) development and issue resolution happens mostly behind closed doors, (2) users pay for and use Microsoft software because they want it to Just Work, (3) if it doesn't do what you want, you are powerless, and (4) updates _frequently_ break things that were working before.
So, first of all, the expectations are different. Believe it or not, most Microsoft users _expect_ things to Just Work. When they don't, there is outrage. Secondly, you don't get to see how these issues are dealt with. So all you get to see is the outrage at Microsoft.
Ah, and let's not forget: bashing Microsoft is fashionable. It's not just on Slashdot anymore.
Excuse me, that "7 K" should have been "17 K".
:-(
That's what I get for editing the preview and then not previewing again.
1. It requires very high pressures (120 GPa)
2. It's only "room temperature" if you keep your room at 7 K (which is a bit unrealistic...)
(Quote swiped from this post)
In my opinion, the whole machinery of logic programming languages can and should be implemented in terms of a general purpose language. Because what logic programming languages really boil down to (correct me if I'm wrong here) is one or a bunch of solving strategies for logic problems, which they are fed as input. That could easily be done by implementing the solving strategies as functions in a general purpose language, especially if that language supports elegant representation of the inputs to your "logic programming library". And the advantage to this is that it is easy to mix your general purpose language with your special purpose language, so you have the power of the former and the convenience of the latter.
One classic example of this is implementing "Prolog" in Lisp. I wrote Prolog in quotes, because what is usually implemented is a language with Lisp syntax and a small subset of the features of Prolog. But still, it's the sort of thing I mean.
``He also said that the target customer (Windows PDA users) wouldn't want to buy an EEE PC because it had Linux on it.''
He's probably right about that one. I know enough people who won't touch Linux unless it's forced on them. Usually because of some imagined defect of Linux's, but the reason doesn't really matter. If it's new and it's with Windows, they'll love it. If it has Linux, they will stay as far away from it as they can.
``No one wants the Microsoft solution where applications need to be certified to run.''
Actually, I do want that solution, and I've advocated it before. What is important, though, is that you can choose your own trust providers (so that the control is not all in a single entity's hands).
Interestingly, this is pretty much what things like apt-get give you. Provided you only install software through apt-get, you get to choose your trust providers (by adding repositories to sources.list), and you can then only install software that has been approved by them.
It works for me. I have about 20000 packages to choose from. They cover my needs. All of them are free software, and none of the ones I have installed have displayed malicious behavior. Did I mention that apt-get also graciously handles dependencies, and makes keeping the system up to date really easy and quick?
And fun. But I also think you can't usufully _design_ your own language without knowing a bunch of different programming paradigms, language constructs, syntaxes, and their strenghts and weaknesses.
I remember I started writing my own programming language when the only programming language I knew was BASIC. Sure enough, it worked around some of the shortcomings I perceived in BASIC. For example, the syntax was more consistent. However, for the most part, it was very much like BASIC. And it used the most ridiculous algorithms and data structures, because BASIC had never taught me to do those right.
Now I know a host of other programming languages, paradigms, syntaxes, language constructs, and data structures. And yet again, I am designing and implementing a programming language. But, this time, it is going to combine the strenghts of various languages into one language, hopefully better than each of the languages its inspired by. And it has some new ideas, too; things that I think no language I know does as well as it could be done.
Oh, and I'm not going to put all my variables in one large string, which then has to be searched on each variable access. Which is what I did in my first programming language implementation. So please. Don't make the mistake I made and think that, since you know one language (and Java and C# are pretty much the same), you know it all.
I'm curious how you do your verification.
I've taken a course on this in university. The tools I remember did basically an exhaustive search of all states in your program, and verified that there were no deadlocks and the properties you specified hold in every state.
Needless to say, this is very memory consuming, and can take a long time. So what you really get to verify is simple models, not your actual application with all its different variables. Also, the tools didn't grok Real World programming languages, so you had to write your model in a language other than the one you would eventually write your application in.
In the end, the impression I got is that formal verification is great, but the tools we used don't tell you _anything_ about the application you write, because that's not the code you ran the verification on.
I know that's just the tools we used in that course, but how do you do it? Which tools do you use, and how do they work?
In fact, I know all of these languages (although Haskell far less than most other languages I know), and I have a hard time wrapping my head around these "patterns".
Anything you want to program ought to be simple.
If there is some commonly occuring functionality (which I guess is what you have "patterns" for, so that you have a guide for implementing that functionality), you factor that functionality out into a function or macro.
After that, programming with it is simple.
You don't have to go and re-implement the pattern every time you need it; you just reuse the implementation you wrote before.
Unless, of course, your programming language does not allow you to write that implementation; usually because it lacks macros or first-class functions.
``I hate to say it but this specialization programming and time spent with other people's frameworks and libraries seems to make me more valuable in my own realm.''
.NET, and more Java and .NET frameworks is obviously going to make you a more valuable Java and .NET programmer.
.NET: .NET is basically Java with some of Java's mistakes fixed, and now Java and .NET are both innovating like crazy to be better than the other. Suddenly, we have generics, proper type systems, multiple languages on the same VM, etc.
Why would you hate to say that? It's the simple truth. Learning more Java and
``You're right, it's a good idea for me to pick up Ruby (or whatever I'm supposed to learn next) because Java is not going to be around forever.''
Since you already know Lisp, I don't think Ruby is going to teach you a lot. Although, of all the programming languages I know, Ruby is the one that offers the least resistance, in that it allows me to simply do what I want to do. But I think its main advantages over Lisp are just that some idioms are slightly less verbose in Ruby (e.g. blocks vs. lambda, a[1] = 42 vs (setf (aref a 1) 42)) and that it ships with libraries for many modern times needs, such as TCP/IP and XML (whereas, with Lisp, these are, at best, not standardized).
``But honestly, I feel a lot of people around me could stop re-inventing the wheel week after week at work and just take a couple days to tweak someone else's solution to work. ''
And that is exactly why I resent Java. The whole culture, from the initial language design up to the latest and greatest framework, is full of reinventing the wheel and, often enough, touting the reinvention as a Great New Thing. Just imagine what could have been accomplished if all the effort that has gone into Java, the standard library, the build tools, etc. etc. had been used to improve an existing language and set of libraries, build tools, etc. And if all the effort that has gone in building yet another build tool, XML library, GUI library, or whatever, because the previous one wasn't good enough, had gone into existing systems, too. And if people looked at the strengths and weaknesses of existing solutions more, so that they would have avoided going through the "make mistakes, fix mistakes, end up with the same thing that somebody else already made before, but incompatible" cycle.
Of course, sometimes it's good to start over. You can't build a solid house on weak foundations. It's not even bad to have multiple languages, build tools, XML libraries, and whatnot. Competition among them will keep everybody motivated to improve their favorite. Just look at Java and
I would recommend Scheme. Not because I recommend you program in it, but because it will change the way you think about programming and programming languages, especially if you also read Structure and Interpretation of Computer Programs (affectionately known as SICP).
Scheme is a small programming language, so you can learn it relatively quickly. This allows you time to read some of the literature about Scheme. And SICP. This will give you insight in the design of programming languages, and how features (like loops, class systems, etc.) can be implemented in terms of simpler constructs, given the right primitives and powerful enough abstractions.
And, in the end, it's the primitives and abstractions that matter. Given the right primitives and abstractions, you can mold your programming language to be anything you want. Scheme, and other languages in the larger Lisp family, are very good at this. That's probably why they are still around, despite tracing their roots back to the 1950s. Other languages are not so good at it, and you will end up writing lots of boilerplate and repetitive code if you program in them.
I could go on and on and list all the insights Scheme has provided me with, but I'd say you go see for yourself. SICP is a good place to start, because it starts at the basics (so you don't need to know Scheme before you start), but gets up to speed really quickly (so you won't get bored). You could also try my Scheme tutorial.
Note that all this is about the 5th revision of Scheme (known as R5RS). R5RS lacks many primitives that would make it useful for Real World applications (just to name one thing, there is nothing about networking). Many implementations of Scheme (and there are many) provide various such primitives - but that's not the point here. The point is about the fundamentals of programming.
As a final remark, if you are used to Java's "everything is part of a class" curfew, Scheme will provide a refreshing change of perspective. R5RS doesn't even have classes. Instead, the focus is on procedures. So you will be decomposing your system in terms of what it does, more than in terms of what real, imaginary, or "forced on you by the programming language" objects it acts on. In my experience, this leads to many small functions, each doing a simple thing, which can then be composed to build your system - or perhaps a very different system that happens to re-use part of the functionality. Unlike Java's classes, each containing a bunch of method, each of which contains gobs of repetitive code...try to adapt _that_ to do something similar, but slightly different. Again, it's all about primitives and abstractions.
``At least in holland a lot of ISP's are happy to advertise with 'download music fast' without having any music service whatsoever. Copyright infringement is one major reason to get one of the more expensive subscriptions, if everyone just went with the cheapest most minimal subscription, you know the one that is plenty for email, the web, gaming etc etc, then ISP's will really feel it in their revenue.''
Also, downloading music and movies (but not software, unless otherwise specified, e.g. in the case of open source) is legal in the Netherlands and many othe EU countries (perhaps all).
IANAL, but I have read the relevant sections of Dutch copyright law. Downloading something from the Internet constitutes making a copy for personal use. This is allowed for all material that comes on media (e.g. music on a CD, where the CD is the medium and the copyrighted work is the music on the CD) except for software. The idea is that file sharing is equivalent to lending your CD to a friend, who then makes a copy for his own use. This is explicitly allowed.
Interestingly, playing a DRMed song or movie that you bought and paid for using an unlicensed player constitutes a circumvention of technical measures and is a criminal offense. Yay DMCA^H^H^H^H^H EUCD.
``When you have that Intel chip that needs a fan that sounds like the Swamp Boat from the WaterBoy movie with Adam Sandler. ''
I have an idea! Maybe the people who care about hd noise _don't_ have Intel chips that need a fan that sounds like the Swamp Boat from the WaterBoy movie with Adam Sandler!
This is not about wear, as far as I know. The flash cards work fine. It's just that Linux starts giving I/O errors after some time. Reboot the system and all is fine again. I think there is a software limit somewhere.
``I've personally had good experience with a flash-based root file system, but I implemented it with a ide-CF adapter.''
I am thinking of trying that, too. It works reliably, right?
I don't have experiences with actual flash drives, but I tried running my Linux system off flash cards. It was horrible. The system used an USB flash card reader (or two, probably), a 1 GB card for the root partition, and an 8 GB card for /home. Both of these were pretty high speed MMC cards.
I had expected the system to be snappy, because I mostly perform many reads on small files. Flash memory has low seek times, right? Well, the system was noticeably slower running from flash than it had been running from harddisk.
But that wasn't the worst. It was usable. The real problem is that the system would lock up after about two to three days. More flash card usage means it locked up sooner. Apparently, there is a limit on the number of writes (or maybe reads, too) you can do in one of the subsystems (USB, mass storage, maybe somewhere else). After that limit is reached, every flash card access failed with an I/O error, and the system would be dead soon enough.
I asked around for help, but didn't find any pointers, much less a solution to the problem. I reverted back to using harddisks.
While I had a good laugh at the article, I think the really real reason people use Linux is even more obvious. Or, much rather, it is obvious that there isn't _one_ such reason. Different people use Linux for different reasons.
I started with Linux out of curiosity. I suppose that goes in the fun department. Nowadays, I use Linux because it is the most efficient: with Debian, I spend very little time on maintenance, and the system keeps working. No other system I have used has come close to Debian in the low-maintenance department. Yet other people use Linux because they think it's cool. Some people use Linux because their boss tells them to. Or because it comes with the system. Or because they can relatively easily customive it to run on whatever outlandish hardware they have. Or because it has already been so customized. I know someone who uses Linux because benchmarks have shown him that, of all OSes, Linux most efficiently takes advantage of his multi-core hardware. Finally, some people use Linux because they think it is in the public domain and they can do whatever they want with it.
A statue of Natalie Portman, naked and petrified?
FTFA: ``There is also no ice cream in space. No freezer.''
What about outside? I imagine that, at least on the shadow side of the station, it's pretty cold out there.