``A couple of years ago Netherlands privatized their health care system and from all reports it has been a great success.''
Is that so? I was under the impression that prices have gone up and coverage has decreased (both of these for the base package - I don't know anything about more expensive/comprehensive arrangements).
``Everyone has a right to property they freely acquired from other freely-acting individual. When the government (or anyone else) starts forcefully taking away that property, that right is being violated. Whether or not some service "works" (according to its own definitions, mind you) for some period of time does not justify a rights violation of any kind.''
``The government is charged with upholding rights. That is done through the courts and by force through through the executive branch. So of course we need armed forced and police to uphold our rights. I'm just saying that such taxation is only justified if it is voluntary. Just as you freely choose to pay some amount for insurance against emergencies, you would also freely choose to pay toward upholding your rights (and the rights of everyone else).''
I don't understand. Do you voluntarily pay taxes to support the military and the police? I.e., could you choose not to, and would the government let you get by without paying? If so, do people who pay the tax get a higher level of protection than those who don't? If the government doesn't let you decide not to pay the tax, than it would seem to me that, by your own words, the government is commiting an unjustified violation of your property rights, no matter how well the police or the military might protect you.
``"fire departments, roads, sewers, electric companies and all the other evil socialist practices America currently has"
Yes, there is no reason why these services could not be provided by private organizations, and in fact all of these services are and have been provided by private organizations. The only differences between the two situations (private, public) are:
1. The public services are funded through an unjustifiable rights violation.
2. Competition among private services gives private companies an incentive to provide the best possible service at the lowest price. Because there is only one provider for a public service (and no competing providers are permitted to exist), there is no incentive for public services to provide the best service or the cheapest service. ''
Correction: private companies have an incentive to maximize profit. Measures that increase profit include, but are not limited to, lowering prices and providing better service.
Note that I am not (in this post) making any claims about what services the government should or shouldn't provide. I am merely pointing out flaws in your arguments.
Also, I wanted to add one thing, which is that I find the notion that OS X or Windows offer consistent user interfaces and "Linux" doesn't quite ridiculous. I can't believe I'm the only one who has ever noticed that OS X, right out of the factory, comes with at least two different window themes: Aqua (white) and Textured (grey). Similarly, Windows apps will show you Windows 95 style widgets, Windows XP style widgets, and various custom widgets (Microsoft Office is full of them). Various applications will do their own widget rendering on every operating system (e.g. applications that use Swing).
The bototm line is that, ultimately, the application decides its look 'n' feel. If all applications you use provide the same look 'n' feel, your desktop will be consistant. If they don't, it won't. That holds true no matter what operating system you're on. Providing a consistent look 'n' feel on Linux is indeed possible. Distros like Ubuntu do that, as do distros that only give you a command line.
``The Kernel is a bit of a special case though, as it's got Linus at the helm, and it *is* the operating system. Having two different kernels would be like MS still running NT and 95 derived OSes parallel to each other.''
Err, no, no, and no, I think.
First of all, there _is_ competition in kernel-land: there are other kernels, such as the FreeBSD kernel and XNU. There certainly is competition between those and Linux. There are also lots of different branches of Linux, and there is competition among those, too. And there is competition _inside_ Linux: different I/O schedulers that compete with one another, etc.
Secondly, whether Linux is or isn't an operating system is at least debatable . Eventually, it boils down to a matter of definitions (what is Linux, and what constitutes an operating system?), but you will need at least _some_ software besides Linux (the kernel) to make it do something useful.
Thirdly, you seem to imply that there isn't something like Microsoft selling different operating systems at the same time in the Linux world. On the contrary, there is a plethora of operating systems, all based on various Linux kernels being offered at this very moment. It has been like that for years, and I hope it will stay that way for years to come. I also hope we will keep the healthy competition between Linux-based and non-Linux-based operating systems, so that we end up with better operating systems for our routers, PCs, PDAs, phones, servers, super computers, refridgerators, airplanes, and everything.
``That depends on whether you think it is acceptable to compel someone to reveal something like that. If, as for example in the US, someone cannot be forced to incriminate himself, then he can just refuse and there is no further recourse.''
Eh? How about the court ordering them to decrypt their victim's data? That would be on the top of my list, if I were to decide the matter.
Of course, that only works once the people you have tracked down have been found guilty. But then, if they haven't been found guilty, you don't have much cause for other measures against them, either. Like the things that many other replies to your post are suggesting...:-(
I don't know who modded that comment funny. I think it's rather insightful and sad. One of the problems with a lot of widely used open-source projects is that there are a lot of people who _would_ contribute (especially by fixing bugs) if the barrier to entry were lower.
Even if the source code is available, the developer tools are freely available, and the knowledge about the necessary languages and tools is free for the taking, there is still a lot that is specific to a given project. Who do you need to contact, who can you ask questions to, how is the source code organized, how do you build it, how should you submit patches, what are the things you absolutely must or must not do, etc. etc. All this is usually poorly documented, if at all. Contributing to an open-source project is a daunting task.
I think X.org has done a lot to make contributing easier, but "easier" doesn't mean easy.
``One of the problems facing OSS is the people who move it forward are the ones who live, breath and feel passionately about the project (99% of the time the core developers), take away those people away and the project usually dies no matter how popular it is.''
For some definition of "dies". Perhaps development on it slows. Perhaps development even stops altogether. But what is there today will be there tomorrow, and will still be doing its job.
Personally, I am satisfied with what my version of X gives me. I am sure there are things that could be improved, but there is nothing I really badly want improved. There are other things that are more important to me than improving X. That's why I am not working on improving X. Perhaps the same goes for other people, and perhaps that's why X.org has stagnated.
Now, if I encountered some issue, e.g. X not running on my new operating system, X not supporting my hardware, some bug that really bugged me, or some feature I thought would be a great addition to X, then I might devote some of my Copious Free Time to working on X. And I can do that, because, X.org being open source, I have access to the source code and have a license that permits me to modify it. I can do that whether or not the project has been abandoned by the rest of the world. And that is where the real difference with proprietary software lies.
OSS is indeed moved forward by the ones who live, breath and feel passionately about the project. And that's not a problem, that's an advantage.
``I'm _guessing_ there already is a law for nonelectronic bullying.''
A law that specifically restricts itself to non-electronic bullying? Why would one want to do that?
I mean, there either is something against bullying or there isn't. If there is, that can be used against cyberbullying as well. If there isn't, I can see a case for a law against bullying. But a law specifically against cyberbullying just doesn't make sense to me. Just like a law specifically against non-electronic bullying doesn't make sense to me. I just don't see what difference it makes if the bullying was or wasn't conducted online.
``THE PERSON WHOSE ID IS STOLEN IS NOT THE VICTIM. The bank is, and the whole process from start to finish ought to be the bank's problem.''
So you are saying that the banks have a problem, and they have somehow found a way to make the people whose credentials were used pay for it? How does this work? How can we stop it?
Because, the way I see it, it's like this: Alice has some account with the Bank. Then Eve comes along and uses Alice's credentials to perform transactions. These transactions benefit Eve, but the Bank believes they were authorized by Alice. When the Bank comes to collect from Alice, Alice denies that she authorized the transactions.
The burden of proof is on the Bank to show that Alice authorized the transactions. The bank demonstrates that Alice's credentials were used to authorize the transactions. What happens then depends on the strength of the credentials: if it is reasonable to assume that someone else could have used Alice's credentials, the fact that Alice's credentials were used does not conclusively demonstracte that Alice authorized the transactions. The bank loses. If, on the other hand, the credentials are such that it is reasonable to assume that only Alice could have authorized the transactions (either by using the credentials herself, or by passing on the necessary information to someone else), then, apparently, Alice did authorize the transactions, and she has to pay.
``The purpose of restricting published work to that which has passed peer review is to ensure that results do not become obsolete. They must uphold the same quality standards that we expect from all scientific disciplines - not blog-style fads that have become popular and at some stage will cease to be popular.''
Err...no, I don't think that's right. There are fads in academic research just like there are pretty much everywhere else. I bet anyone can find tons of old journal publications that, nowadays, aren't very interesting anymore. So that's not it.
I think journals have the same advantage over do-it-yourself online publication that encyclopedias have over Wikipedia: there is a relatively small team and a single organization that is responsible for quality control. Trust those people to do a good job, and you can trust the publications. Also, the rate at which new information is added to the total body of information is lower than in more distributed systems, which means that sifting through it is less overwhelming. Both of these things are double edged swords, though.
My personal experience and opinion is that Wikipedia, contrary to my expectations, does a better job of making high-quality information available and accessible than anything I have compared it with. However, that comparison does not include scientific journals. My experience with those has been that they erect to many barriers in front of their information. I just find things more quickly by doing a simple web search (which may, of course, actually include journal publications in its results). The short of it is that I have pretty much abandoned academic journals.
'Whoever transmits in interstate or foreign commerce any communication, with the intent to coerce, intimidate, harass, or cause substantial emotional distress to a person, using electronic means to support severe, repeated, and hostile behavior, shall be fined under this title or imprisoned not more than two years, or both.'
Why only when using electronic means? I should think it's not the tool you use that is important, but what you do.
Just because there seems to be a lot of confusion about this topic, let me weigh in with what I think is the whole story as far as DOS and the 640 KB limit are concerned.
MS-DOS was initialyl created for the IBM PC. The IBM PC had an Intel 8088 CPU, which is a 16-bit CPU with a 20-bit address bus. The 20-bit address bus means that it could address at most 1 MB of memory.
The way that worked in software is that a memory address is composed of a 16-bit segment and a 16-bit offset within that segment. Each segment is 64 KB in size (the maximum that a 16-bit offset can address), and segments are stored 16 bytes from one another (so segment 0 starts at address 0, segment 1 starts at address 16, and so on). This means two things: first of all that segments overlap, and secondly, that the total memory addressable by this scheme is a little over 1MB; 65520 bytes more, to be exact.
Now, things were organized such that the first 640 KB were available as RAM, whereas the addresses from there up to 1 MB were reserved for hardware, BIOS, etc. _This_ is were the 640 KB limit comes from: it was in the organization of the hardware.
But the story gets more complicated from there. Newer CPUs shipped in PC and clones actually had more than 20-bits to address memory: the 286 had a 24-bit address bus, and CPUs from the 386 (excluding the SX) up had 32-bit address buses. This means the little area from 1MB to 1MB+65520 was also available (this area is called "high memory" in DOS). Also, not all of the areas between 640 KB and 1MB were in use, and parts of that space could be mapped to memory. These are called Upper Memory Blocks in DOS. So DOS does actually allow using a bit more than 640 KB of memory.
In addition to all this, there were (at least) two standards for using memory outside what could be addressed by the 8088's segment+offset scheme. There was EMS (Expanded Memory System), which mapped memory outside the range to addresess inside the range. You would temporarily map some logical address 1MB, thus allowing you to use memory > 1MB.
XMS (eXtended Memory System) was the more popular scheme. I am not 100% sure how it works, but I think it provides an API that allows you to copy bytes from the addressable memory ( 1MB) memory and back.
That's the story as far as DOS goes. Clearly, DOS allowed you to use more than 640 KB of memory, so the parent is right.
On the other hand, the 640 KB limit is very noticeable when programming for DOS in real mode. Therefore, later programs usually stepped outside DOS and put the CPU in protected mode, which allows addressing using all 24 (286 and up) or 32 (386 and up) bits of the address bus, without jumping through hoops like XMS or EMS. But that's completely outside DOS. So you get the 640 KB limit removed by shedding DOS. In a sense, then, the magic 640 KB limit really is a DOS relic. Other operating systems, like Linux, never had that limit.
Incidentally, there are some tricks you can do to get both DOS and full 32-bit addressing. One such trick is using DPMS, which basically goes back and forth between real mode (to use DOS system calls) and protected mode (to address all memory), and supports virtual memory, too. Another is to go into what is sometimes called unreal mode, where you switch into protected mode, set your segments to be 4GB in size, and switch back into real mode. As long as you don't write the segment registers again, your segments stay 4GB in size, and you can address them using 32-bit offsets.
So there it is. The whole story about DOS and the 640 KB limit, brought to you by an old assembly hacker who has worked with all this stuff. And they say Linux is hard to use.;-)
``Also, slightly off-topic, but is anyone else concerned about the security implications of pushing more and more languages/capabilities/ functionality into the web browser''
Yes and no.
In principle, no. As long as the web browser has a set of clearly identified things it can do (e.g. render graphics, perform HTTP requests) and can do nothing else, there can never be a problem. In that case, more languages, libraries, etc. to run in the web browser would make it better; perhaps we could even get some decent model for rich Internet applications that way.
In practice, of course, web browsers are horribly complex monstrosities written in unsafe languages, so one can hardly be sure what the browser can and can't do. In that case, we should be concerned about what new languages, libraries, etc. running in the browser will do to our security. The combination of filesystem access and running untrusted code, which all major browsers provide, is already quite interesting.
``Which proves this article's premise completely wrong. The only people who ARE interested are the malicious folks, which will be almost your entire "full disclosure" audience. Full disclosure is a great way to give the malicious folks a head start, and won't do one tiny little thing towards linking a product's popularity to its security.''
I am offended by your comment. I am in favor of full disclosure, and I am not a black hat. I know there are many people like me.
Also, your analysis is wrong on both counts. Full disclosure doesn't give anyone a head start. On the contrary, it informs everybody of the flaw at the same time. That does indeed include the black hats, but also the vendor and the users. This allows the black hats to develop exploits, but it also allows the vendor to work on a fix, and the users to implement temporary stopgaps. The alternative is, pretty much, not informing the users of the flaw - thereby leaving them unaware that a vulnerability has been discovered. As for the black hats: they work hard to find security flaws and avoid full disclosure - after all, as long as only they know the flaw exists, they can exploit it for fun and profit.
With regard to linking a product's popularity to its security: I know of two things that will do that. The first is users feeling victimized by the bad security of the product they have. The other is making actual and potential users aware of the security risks of a product. Full discloruse brings the insecurity of a product out in the open, which is a step towards the latter and can also help with the former. Of course, the effect is going to be rather limited as long as users don't care very much, but I can tell you that the effect is there.
I can't speak for others, but I won't give up my VGA until an alternative comes along that actually does better.
What's with DVI's limited bandwidth?
And HD...currently just seems a compatibility mess (partially reinforced by DRM).
Meanwhile, I get great image quality _and_ high resolution _and_ high refresh rate with VGA, and it works with all computers and all monitors I have. That's very hard to beat.
``I don't think that Ruby is bad, not by a long shot. It's seems fairly decent and it doesn't seem to be lacking anything necessary. I'm just curious as to why someone would pick Ruby over some other language. I'm not quite understanding what the "killer app" of Ruby is. I'm not sure why this language had to be created.''
Ruby was inspired by a number of good and useful programming languages, such as Lisp, Smalltalk, Perl, and Python. It combines the good features of those into a single language. The result is a language that is very powerful, has clean syntax, is easy to get started with, and allows a little code to do a lot of work.
As for a killer app, I don't think there really is one. Ruby is and has always been a general-purpose language. It got its 15 minutes of fame with Rails, but that has since been cloned in other languages. Nowadays, Ruby is just good at many of the same things Perl is good at, and good at many of the same things Python is good at. I personally prefer Ruby, because it is a very well thought out language and, coming from Lisp, it feels natural to me. Still, I don't think Ruby is that much better that people should or will be switching in droves. It's an incremental improvement over already good and useful languages, not a revolution.
Now, for some specifics.
From Perl, Ruby takes first-class regular expressions. Many Ruby modules are also ports of Perl modules.
From Python, Ruby takes clean syntax. There's quite a lot of competition between Ruby and Python, so I imagine there is a lot of "me too" on both sides.
From Smalltalk, Ruby takes the object system (everything is an object, every object belongs to a class), and blocks (kind of like anonymous functions, but with special syntax). Blocks, especially, are very powerful, as you can use them to (almost, I have to say as a Lisp programmer) implement your own control structures; loops, iterators, etc.
From Lisp, or maybe from other languages that have these features, Ruby takes garbage collection, anonymous functions, dynamic typing, call/cc, symbols as first-class values, printing of objects in Ruby-readable form, a read-eval-print loop (enter code, have it evaluated and the results printed) and probably a bunch of other features I am too tired to think of right now (but not macros, alas).
Ruby also has exceptions, the printf family of functions, and a number of other features commonly found in modern programming languages.
The kicker is that it has all this in a single, coherent language, with a syntax that is easy to understand and learn, and few great pitfalls. Mostly, whether you already know a programming language or not, you can just start coding in Ruby, and it will be easy. There aren't lots of irritating silly parentheses in Ruby, neither is there a difference between scalar and list context. No buffer overflows, no integer overflows, no memory leaks. You don't need to change the way you think, you don't need an IDE. It's easy to get started with, and yet doesn't suffer from problems that languages that are easy to get started with usually have: bad design, limited expressive power, only really being suitable to one domain, etc.
Finally, some code, just for kicks:
# Define an array with first names and one with last names first_names = [ 'Alice', 'Bob', 'Charlie', 'Deborah', 'Eve' ] last_names = [ 'Cooper', 'Jones', 'Smith' ]
# Define a class Person # Each person has a first name and a last name # which have to be passed to the constructor # and can be accessed using an accessor class Person
def initialize first_name, last_name
@first_name = first_name
@last_name = last_name
end
attr_accessor:first_name,:last_name end
# Add a pick method to the class Array # The pick method returns an element from the array at random class Array
def pick
Finally, something is being done about the taskbar. It's a neat enough interface if you have only a few windows open, but quickly becomes a useless waste of screen space once you open more windows. I'm happy that Microsoft is finally rethinking the idea. There are various alternatives that would be better, so the chance for improvement is certainly there. And here's to hoping GNOME and KDE will follow suit and improve theirs...
I think the deal is that, ultimately, lower-level languages (assembly is lower than C, which is lower than C++, which is lower than Java) allow you to gain better performance than you could achieve with higher-level languages.
Whether you will actually achieve the highest possible performance depends on whether you actually write the most efficient code possible. This, in turn, depends on your skills and the time you have to complete the project.
Thus, what you will see in practice is that there is a lot of variance in the performance of programs written in lower-level languages, and less variance in the performance of higher-level languages. Libraries also have a huge influence here: the more code you use from a library, the faster you will complete the project and the less variance there will be between your program that uses that library and someone else's program that uses that library.
The final result will probably be that the fastest programs are in the lowest level languages (provided these programs exist at all), but, largely, the speed scales will overlap. It may even be that the slowest programs in a lower-level language are slower than the slowest programs in a higher-level language.
Thus, it is not a priory obvious that lower-level programming languages will yield faster programs than higher-level ones.
For another data point, have a look at OCaml. With garbage collection, polymorphism, classes and objects, and type inference, it's definitely a high-level language. In my experience, it's much nicer to program in than Java, and the implementation offers run-time performance that is about on par with Java and often a lot better.
Well, I guess Konqueror isn't going to win. It seems I'm stuck on "Question 2 of 10". Anyway, I lost interest. Too many trivia questions in there. I'm good at those, but I don't think they say anything about my IQ.
``The goal should be to encourage innovation and creativity.''
Do we actually need to encourage these? Do we need to create laws that give inventors a way to profit from their inventions more than others?
I've been mostly staying away from the debate, because there are too many things in there that I have no idea about. But the two things that I do know are that (1) a lot of people who participate in the debate don't know all these things, either, and (2) I resent patents for denying people who invent something that happens to have been patented from using their invention.
So? You got modded insightful, but I don't see why. No offense to you, but I don't think any of your points are valid.
``1) My example was done to show how quick and easy it would be to set up and populate a table in Python.''
Writing code without injection vulnerabilities doesn't have to be any less quick and easy. Given that, why would you choose the quick, easy, and vulnerable way over the quick, easy, and secure way?
``2) He's explicitly mentioned several times that this is for his own private non-web use.''
Just because you don't see any threats to your software at present doesn't mean you should write it in an insecure way. And if you're posting your code in a public forum, I feel you have some responsibility to present good code or at the very least warn about its weaknesses.
``3) Your fly is open.''
Thanks for pointing that out to me. *closes zip* Now, I hope you will react similarly to people pointing out flaws in your code.
As a final note, many programming languages lamentably come with APIs that make it easy to do things insecurely and no easy way to do things securely. I feel this is something we should be working on, because if the secure way is as easy or easier to code than the vulnerable way, I am sure software security will improve.
``Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption.''
I'm not sure that is actually the case. It would make sense if copyleft deterred some companies...but I could also see it actually attracting them. I don't know how the balance works out.
I think the problem with all of these is that they consist of too much hype and too little sense. Also, a lot of them are horribly over-engineered.
Taking SOAP as an example, because that's the one I know best. What you need is some way to communicate data to another party. What you get is something that does that, but in about the most verbose and latency-sensitive way imaginable. Yes, it's standards-based, which is a Good Thing, and it's human-readable, which is also advantageous.
On the other hand, the standard is apparently complex enough that various implementations implement distinct subsets...meaning interoperability is hit and miss. And seriously...HTTP and XML? Horribly inefficient.
All I know about Java RMI is that it was a horrible pain to get everything set up right so that it would work...and even then, of course, it's _Java_ RMI, so I'm not sure it's the best choice if you don't want to prescribe a particular platform or object model.
What I think all these have in common is that they try to automagically solve a problem that can hardly be solved automagically. The premise, as far as I understand, of protocols like this is that they will let you exchange objects from your program with programs on remote machines, without you having to do any work on it. But, in practice, it's hard to decide how to go about that without specific knowledge of how these objects will be used. Specifically, objects tend to be part of a graph...which parts of the graph do you send over the wire? And then there's all the actually hard problems related to distributed programming...
As for the protocols, I've always thought it shouldn't be that hard. Lisp has this thing where you can read and write Lisp objects. Write it out and read it back in and you'll get an equal object. This is incredibly useful for many things, including debugging, but also makes it easy to envision a protocol for distributed computing - especially when you consider that Lisp programs also consist of Lisp objects.
On the other hand, Lisp's read-write protocol isn't the most efficient as far as parsing and transmission are concerned. So something could be gained there. And not all objects can be read back in - for some it would even be a Bad Thing if they could. And none of the harder problems (like which parts of the graph to send) have been addressed yet. On the gripping hand, I honestly feel it's already better than SOAP.
For the rest, I think the trick is to keep things simple. Think of what you want to send. Encode that using some simple, efficient encoding, and send it. Don't shoot for automagic, Just Works exchange of arbitrary program objects. Think about what you really need to send and send only that.
Oh, and don't draw in layers and layers of frameworks, please.
``you don't get the Nobel prize for an article in "Il sore 24 ore"''
But you do get to the front page of Slashdot!
More seriously, the established journals are often hideously slow in publishing stuff, and often dare to charge you for it, too. In the age of the Internet, all that can be dispensed with. You can get your discoveries and inventions published, peer reviewed, and communicated to the masses, all for free and without having to wait on some organization's release cycle.
You can also, of course, use the Internet to spread lies and misinformation, create fake peer reviews, and communicate all that to the masses, all for free and without having to wait on some organization's release cycle.
Slashdot Mirror
``A couple of years ago Netherlands privatized their health care system and
from all reports it has been a great success.''
Is that so? I was under the impression that prices have gone up and coverage has decreased (both of these for the base package - I don't know anything about more expensive/comprehensive arrangements).
``Everyone has a right to property they freely acquired from other freely-acting individual. When the government (or anyone else) starts forcefully taking away that property, that right is being violated. Whether or not some service "works" (according to its own definitions, mind you) for some period of time does not justify a rights violation of any kind.''
``The government is charged with upholding rights. That is done through the courts and by force through through the executive branch. So of course we need armed forced and police to uphold our rights. I'm just saying that such taxation is only justified if it is voluntary. Just as you freely choose to pay some amount for insurance against emergencies, you would also freely choose to pay toward upholding your rights (and the rights of everyone else).''
I don't understand. Do you voluntarily pay taxes to support the military and the police? I.e., could you choose not to, and would the government let you get by without paying? If so, do people who pay the tax get a higher level of protection than those who don't? If the government doesn't let you decide not to pay the tax, than it would seem to me that, by your own words, the government is commiting an unjustified violation of your property rights, no matter how well the police or the military might protect you.
``"fire departments, roads, sewers, electric companies and all the other evil socialist practices America currently has"
Yes, there is no reason why these services could not be provided by private organizations, and in fact all of these services are and have been provided by private organizations. The only differences between the two situations (private, public) are:
1. The public services are funded through an unjustifiable rights violation.
2. Competition among private services gives private companies an incentive to provide the best possible service at the lowest price. Because there is only one provider for a public service (and no competing providers are permitted to exist), there is no incentive for public services to provide the best service or the cheapest service. ''
Correction: private companies have an incentive to maximize profit. Measures that increase profit include, but are not limited to, lowering prices and providing better service.
Note that I am not (in this post) making any claims about what services the government should or shouldn't provide. I am merely pointing out flaws in your arguments.
You are right, and I hope someone mods you up.
Also, I wanted to add one thing, which is that I find the notion that OS X or Windows offer consistent user interfaces and "Linux" doesn't quite ridiculous. I can't believe I'm the only one who has ever noticed that OS X, right out of the factory, comes with at least two different window themes: Aqua (white) and Textured (grey). Similarly, Windows apps will show you Windows 95 style widgets, Windows XP style widgets, and various custom widgets (Microsoft Office is full of them). Various applications will do their own widget rendering on every operating system (e.g. applications that use Swing).
The bototm line is that, ultimately, the application decides its look 'n' feel. If all applications you use provide the same look 'n' feel, your desktop will be consistant. If they don't, it won't. That holds true no matter what operating system you're on. Providing a consistent look 'n' feel on Linux is indeed possible. Distros like Ubuntu do that, as do distros that only give you a command line.
``The Kernel is a bit of a special case though, as it's got Linus at the helm, and it *is* the operating system. Having two different kernels would be like MS still running NT and 95 derived OSes parallel to each other.''
Err, no, no, and no, I think.
First of all, there _is_ competition in kernel-land: there are other kernels, such as the FreeBSD kernel and XNU. There certainly is competition between those and Linux. There are also lots of different branches of Linux, and there is competition among those, too. And there is competition _inside_ Linux: different I/O schedulers that compete with one another, etc.
Secondly, whether Linux is or isn't an operating system is at least debatable . Eventually, it boils down to a matter of definitions (what is Linux, and what constitutes an operating system?), but you will need at least _some_ software besides Linux (the kernel) to make it do something useful.
Thirdly, you seem to imply that there isn't something like Microsoft selling different operating systems at the same time in the Linux world. On the contrary, there is a plethora of operating systems, all based on various Linux kernels being offered at this very moment. It has been like that for years, and I hope it will stay that way for years to come. I also hope we will keep the healthy competition between Linux-based and non-Linux-based operating systems, so that we end up with better operating systems for our routers, PCs, PDAs, phones, servers, super computers, refridgerators, airplanes, and everything.
``That depends on whether you think it is acceptable to compel someone to reveal something like that. If, as for example in the US, someone cannot be forced to incriminate himself, then he can just refuse and there is no further recourse.''
:-(
Eh? How about the court ordering them to decrypt their victim's data? That would be on the top of my list, if I were to decide the matter.
Of course, that only works once the people you have tracked down have been found guilty. But then, if they haven't been found guilty, you don't have much cause for other measures against them, either. Like the things that many other replies to your post are suggesting...
I don't know who modded that comment funny. I think it's rather insightful and sad. One of the problems with a lot of widely used open-source projects is that there are a lot of people who _would_ contribute (especially by fixing bugs) if the barrier to entry were lower.
Even if the source code is available, the developer tools are freely available, and the knowledge about the necessary languages and tools is free for the taking, there is still a lot that is specific to a given project. Who do you need to contact, who can you ask questions to, how is the source code organized, how do you build it, how should you submit patches, what are the things you absolutely must or must not do, etc. etc. All this is usually poorly documented, if at all. Contributing to an open-source project is a daunting task.
I think X.org has done a lot to make contributing easier, but "easier" doesn't mean easy.
``One of the problems facing OSS is the people who move it forward are the ones who live, breath and feel passionately about the project (99% of the time the core developers), take away those people away and the project usually dies no matter how popular it is.''
For some definition of "dies". Perhaps development on it slows. Perhaps development even stops altogether. But what is there today will be there tomorrow, and will still be doing its job.
Personally, I am satisfied with what my version of X gives me. I am sure there are things that could be improved, but there is nothing I really badly want improved. There are other things that are more important to me than improving X. That's why I am not working on improving X. Perhaps the same goes for other people, and perhaps that's why X.org has stagnated.
Now, if I encountered some issue, e.g. X not running on my new operating system, X not supporting my hardware, some bug that really bugged me, or some feature I thought would be a great addition to X, then I might devote some of my Copious Free Time to working on X. And I can do that, because, X.org being open source, I have access to the source code and have a license that permits me to modify it. I can do that whether or not the project has been abandoned by the rest of the world. And that is where the real difference with proprietary software lies.
OSS is indeed moved forward by the ones who live, breath and feel passionately about the project. And that's not a problem, that's an advantage.
Hey, it could be worse.
In Soviet Russia, algae slime has YOU!
``I'm _guessing_ there already is a law for nonelectronic bullying.''
A law that specifically restricts itself to non-electronic bullying? Why would one want to do that?
I mean, there either is something against bullying or there isn't. If there is, that can be used against cyberbullying as well. If there isn't, I can see a case for a law against bullying. But a law specifically against cyberbullying just doesn't make sense to me. Just like a law specifically against non-electronic bullying doesn't make sense to me. I just don't see what difference it makes if the bullying was or wasn't conducted online.
``THE PERSON WHOSE ID IS STOLEN IS NOT THE VICTIM. The bank is, and the whole process from start to finish ought to be the bank's problem.''
So you are saying that the banks have a problem, and they have somehow found a way to make the people whose credentials were used pay for it? How does this work? How can we stop it?
Because, the way I see it, it's like this: Alice has some account with the Bank. Then Eve comes along and uses Alice's credentials to perform transactions. These transactions benefit Eve, but the Bank believes they were authorized by Alice. When the Bank comes to collect from Alice, Alice denies that she authorized the transactions.
The burden of proof is on the Bank to show that Alice authorized the transactions. The bank demonstrates that Alice's credentials were used to authorize the transactions. What happens then depends on the strength of the credentials: if it is reasonable to assume that someone else could have used Alice's credentials, the fact that Alice's credentials were used does not conclusively demonstracte that Alice authorized the transactions. The bank loses. If, on the other hand, the credentials are such that it is reasonable to assume that only Alice could have authorized the transactions (either by using the credentials herself, or by passing on the necessary information to someone else), then, apparently, Alice did authorize the transactions, and she has to pay.
Did I miss anything?
``The purpose of restricting published work to that which has passed peer review is to ensure that results do not become obsolete. They must uphold the same quality standards that we expect from all scientific disciplines - not blog-style fads that have become popular and at some stage will cease to be popular.''
Err...no, I don't think that's right. There are fads in academic research just like there are pretty much everywhere else. I bet anyone can find tons of old journal publications that, nowadays, aren't very interesting anymore. So that's not it.
I think journals have the same advantage over do-it-yourself online publication that encyclopedias have over Wikipedia: there is a relatively small team and a single organization that is responsible for quality control. Trust those people to do a good job, and you can trust the publications. Also, the rate at which new information is added to the total body of information is lower than in more distributed systems, which means that sifting through it is less overwhelming. Both of these things are double edged swords, though.
My personal experience and opinion is that Wikipedia, contrary to my expectations, does a better job of making high-quality information available and accessible than anything I have compared it with. However, that comparison does not include scientific journals. My experience with those has been that they erect to many barriers in front of their information. I just find things more quickly by doing a simple web search (which may, of course, actually include journal publications in its results). The short of it is that I have pretty much abandoned academic journals.
'Whoever transmits in interstate or foreign commerce any communication, with the intent to coerce, intimidate, harass, or cause substantial emotional distress to a person, using electronic means to support severe, repeated, and hostile behavior, shall be fined under this title or imprisoned not more than two years, or both.'
Why only when using electronic means? I should think it's not the tool you use that is important, but what you do.
Just because there seems to be a lot of confusion about this topic, let me weigh in with what I think is the whole story as far as DOS and the 640 KB limit are concerned.
;-)
MS-DOS was initialyl created for the IBM PC. The IBM PC had an Intel 8088 CPU, which is a 16-bit CPU with a 20-bit address bus. The 20-bit address bus means that it could address at most 1 MB of memory.
The way that worked in software is that a memory address is composed of a 16-bit segment and a 16-bit offset within that segment. Each segment is 64 KB in size (the maximum that a 16-bit offset can address), and segments are stored 16 bytes from one another (so segment 0 starts at address 0, segment 1 starts at address 16, and so on). This means two things: first of all that segments overlap, and secondly, that the total memory addressable by this scheme is a little over 1MB; 65520 bytes more, to be exact.
Now, things were organized such that the first 640 KB were available as RAM, whereas the addresses from there up to 1 MB were reserved for hardware, BIOS, etc. _This_ is were the 640 KB limit comes from: it was in the organization of the hardware.
But the story gets more complicated from there. Newer CPUs shipped in PC and clones actually had more than 20-bits to address memory: the 286 had a 24-bit address bus, and CPUs from the 386 (excluding the SX) up had 32-bit address buses. This means the little area from 1MB to 1MB+65520 was also available (this area is called "high memory" in DOS). Also, not all of the areas between 640 KB and 1MB were in use, and parts of that space could be mapped to memory. These are called Upper Memory Blocks in DOS. So DOS does actually allow using a bit more than 640 KB of memory.
In addition to all this, there were (at least) two standards for using memory outside what could be addressed by the 8088's segment+offset scheme. There was EMS (Expanded Memory System), which mapped memory outside the range to addresess inside the range. You would temporarily map some logical address 1MB, thus allowing you to use memory > 1MB.
XMS (eXtended Memory System) was the more popular scheme. I am not 100% sure how it works, but I think it provides an API that allows you to copy bytes from the addressable memory ( 1MB) memory and back.
That's the story as far as DOS goes. Clearly, DOS allowed you to use more than 640 KB of memory, so the parent is right.
On the other hand, the 640 KB limit is very noticeable when programming for DOS in real mode. Therefore, later programs usually stepped outside DOS and put the CPU in protected mode, which allows addressing using all 24 (286 and up) or 32 (386 and up) bits of the address bus, without jumping through hoops like XMS or EMS. But that's completely outside DOS. So you get the 640 KB limit removed by shedding DOS. In a sense, then, the magic 640 KB limit really is a DOS relic. Other operating systems, like Linux, never had that limit.
Incidentally, there are some tricks you can do to get both DOS and full 32-bit addressing. One such trick is using DPMS, which basically goes back and forth between real mode (to use DOS system calls) and protected mode (to address all memory), and supports virtual memory, too. Another is to go into what is sometimes called unreal mode, where you switch into protected mode, set your segments to be 4GB in size, and switch back into real mode. As long as you don't write the segment registers again, your segments stay 4GB in size, and you can address them using 32-bit offsets.
So there it is. The whole story about DOS and the 640 KB limit, brought to you by an old assembly hacker who has worked with all this stuff. And they say Linux is hard to use.
``Also, slightly off-topic, but is anyone else concerned about the security implications of pushing more and more languages/capabilities/ functionality into the web browser''
Yes and no.
In principle, no. As long as the web browser has a set of clearly identified things it can do (e.g. render graphics, perform HTTP requests) and can do nothing else, there can never be a problem. In that case, more languages, libraries, etc. to run in the web browser would make it better; perhaps we could even get some decent model for rich Internet applications that way.
In practice, of course, web browsers are horribly complex monstrosities written in unsafe languages, so one can hardly be sure what the browser can and can't do. In that case, we should be concerned about what new languages, libraries, etc. running in the browser will do to our security. The combination of filesystem access and running untrusted code, which all major browsers provide, is already quite interesting.
``Which proves this article's premise completely wrong. The only people who ARE interested are the malicious folks, which will be almost your entire "full disclosure" audience. Full disclosure is a great way to give the malicious folks a head start, and won't do one tiny little thing towards linking a product's popularity to its security.''
I am offended by your comment. I am in favor of full disclosure, and I am not a black hat. I know there are many people like me.
Also, your analysis is wrong on both counts. Full disclosure doesn't give anyone a head start. On the contrary, it informs everybody of the flaw at the same time. That does indeed include the black hats, but also the vendor and the users. This allows the black hats to develop exploits, but it also allows the vendor to work on a fix, and the users to implement temporary stopgaps. The alternative is, pretty much, not informing the users of the flaw - thereby leaving them unaware that a vulnerability has been discovered. As for the black hats: they work hard to find security flaws and avoid full disclosure - after all, as long as only they know the flaw exists, they can exploit it for fun and profit.
With regard to linking a product's popularity to its security: I know of two things that will do that. The first is users feeling victimized by the bad security of the product they have. The other is making actual and potential users aware of the security risks of a product. Full discloruse brings the insecurity of a product out in the open, which is a step towards the latter and can also help with the former. Of course, the effect is going to be rather limited as long as users don't care very much, but I can tell you that the effect is there.
I can't speak for others, but I won't give up my VGA until an alternative comes along that actually does better.
What's with DVI's limited bandwidth?
And HD...currently just seems a compatibility mess (partially reinforced by DRM).
Meanwhile, I get great image quality _and_ high resolution _and_ high refresh rate with VGA, and it works with all computers and all monitors I have. That's very hard to beat.
decent and it doesn't seem to be lacking anything necessary. I'm just
curious as to why someone would pick Ruby over some other language. I'm
not quite understanding what the "killer app" of Ruby is. I'm not sure
why this language had to be created.''
Ruby was inspired by a number of good and useful programming languages, such as Lisp, Smalltalk, Perl, and Python. It combines the good features of those into a single language. The result is a language that is very powerful, has clean syntax, is easy to get started with, and allows a little code to do a lot of work.
As for a killer app, I don't think there really is one. Ruby is and has always been a general-purpose language. It got its 15 minutes of fame with Rails, but that has since been cloned in other languages. Nowadays, Ruby is just good at many of the same things Perl is good at, and good at many of the same things Python is good at. I personally prefer Ruby, because it is a very well thought out language and, coming from Lisp, it feels natural to me. Still, I don't think Ruby is that much better that people should or will be switching in droves. It's an incremental improvement over already good and useful languages, not a revolution.
Now, for some specifics.
From Perl, Ruby takes first-class regular expressions. Many Ruby modules are also ports of Perl modules.
From Python, Ruby takes clean syntax. There's quite a lot of competition between Ruby and Python, so I imagine there is a lot of "me too" on both sides.
From Smalltalk, Ruby takes the object system (everything is an object, every object belongs to a class), and blocks (kind of like anonymous functions, but with special syntax). Blocks, especially, are very powerful, as you can use them to (almost, I have to say as a Lisp programmer) implement your own control structures; loops, iterators, etc.
From Lisp, or maybe from other languages that have these features, Ruby takes garbage collection, anonymous functions, dynamic typing, call/cc, symbols as first-class values, printing of objects in Ruby-readable form, a read-eval-print loop (enter code, have it evaluated and the results printed) and probably a bunch of other features I am too tired to think of right now (but not macros, alas).
Ruby also has exceptions, the printf family of functions, and a number of other features commonly found in modern programming languages.
The kicker is that it has all this in a single, coherent language, with a syntax that is easy to understand and learn, and few great pitfalls. Mostly, whether you already know a programming language or not, you can just start coding in Ruby, and it will be easy. There aren't lots of irritating silly parentheses in Ruby, neither is there a difference between scalar and list context. No buffer overflows, no integer overflows, no memory leaks. You don't need to change the way you think, you don't need an IDE. It's easy to get started with, and yet doesn't suffer from problems that languages that are easy to get started with usually have: bad design, limited expressive power, only really being suitable to one domain, etc.
Finally, some code, just for kicks:
Finally, something is being done about the taskbar. It's a neat enough interface if you have only a few windows open, but quickly becomes a useless waste of screen space once you open more windows. I'm happy that Microsoft is finally rethinking the idea. There are various alternatives that would be better, so the chance for improvement is certainly there. And here's to hoping GNOME and KDE will follow suit and improve theirs...
I think the deal is that, ultimately, lower-level languages (assembly is lower than C, which is lower than C++, which is lower than Java) allow you to gain better performance than you could achieve with higher-level languages.
Whether you will actually achieve the highest possible performance depends on whether you actually write the most efficient code possible. This, in turn, depends on your skills and the time you have to complete the project.
Thus, what you will see in practice is that there is a lot of variance in the performance of programs written in lower-level languages, and less variance in the performance of higher-level languages. Libraries also have a huge influence here: the more code you use from a library, the faster you will complete the project and the less variance there will be between your program that uses that library and someone else's program that uses that library.
The final result will probably be that the fastest programs are in the lowest level languages (provided these programs exist at all), but, largely, the speed scales will overlap. It may even be that the slowest programs in a lower-level language are slower than the slowest programs in a higher-level language.
Thus, it is not a priory obvious that lower-level programming languages will yield faster programs than higher-level ones.
For another data point, have a look at OCaml. With garbage collection, polymorphism, classes and objects, and type inference, it's definitely a high-level language. In my experience, it's much nicer to program in than Java, and the implementation offers run-time performance that is about on par with Java and often a lot better.
Well, I guess Konqueror isn't going to win. It seems I'm stuck on "Question 2 of 10". Anyway, I lost interest. Too many trivia questions in there. I'm good at those, but I don't think they say anything about my IQ.
``The goal should be to encourage innovation and creativity.''
Do we actually need to encourage these? Do we need to create laws that give inventors a way to profit from their inventions more than others?
I've been mostly staying away from the debate, because there are too many things in there that I have no idea about. But the two things that I do know are that (1) a lot of people who participate in the debate don't know all these things, either, and (2) I resent patents for denying people who invent something that happens to have been patented from using their invention.
That's my 2 cents.
So? You got modded insightful, but I don't see why. No offense to you, but I don't think any of your points are valid.
``1) My example was done to show how quick and easy it would be to set up and populate a table in Python.''
Writing code without injection vulnerabilities doesn't have to be any less quick and easy. Given that, why would you choose the quick, easy, and vulnerable way over the quick, easy, and secure way?
``2) He's explicitly mentioned several times that this is for his own private non-web use.''
Just because you don't see any threats to your software at present doesn't mean you should write it in an insecure way. And if you're posting your code in a public forum, I feel you have some responsibility to present good code or at the very least warn about its weaknesses.
``3) Your fly is open.''
Thanks for pointing that out to me. *closes zip* Now, I hope you will react similarly to people pointing out flaws in your code.
As a final note, many programming languages lamentably come with APIs that make it easy to do things insecurely and no easy way to do things securely. I feel this is something we should be working on, because if the secure way is as easy or easier to code than the vulnerable way, I am sure software security will improve.
``Glad to see more and more companies moving away from GPL, understanding that it will only limit the potential adoption.''
I'm not sure that is actually the case. It would make sense if copyleft deterred some companies...but I could also see it actually attracting them. I don't know how the balance works out.
I think the problem with all of these is that they consist of too much hype and too little sense. Also, a lot of them are horribly over-engineered.
Taking SOAP as an example, because that's the one I know best. What you need is some way to communicate data to another party. What you get is something that does that, but in about the most verbose and latency-sensitive way imaginable. Yes, it's standards-based, which is a Good Thing, and it's human-readable, which is also advantageous.
On the other hand, the standard is apparently complex enough that various implementations implement distinct subsets...meaning interoperability is hit and miss. And seriously...HTTP and XML? Horribly inefficient.
All I know about Java RMI is that it was a horrible pain to get everything set up right so that it would work...and even then, of course, it's _Java_ RMI, so I'm not sure it's the best choice if you don't want to prescribe a particular platform or object model.
What I think all these have in common is that they try to automagically solve a problem that can hardly be solved automagically. The premise, as far as I understand, of protocols like this is that they will let you exchange objects from your program with programs on remote machines, without you having to do any work on it. But, in practice, it's hard to decide how to go about that without specific knowledge of how these objects will be used. Specifically, objects tend to be part of a graph...which parts of the graph do you send over the wire? And then there's all the actually hard problems related to distributed programming...
As for the protocols, I've always thought it shouldn't be that hard. Lisp has this thing where you can read and write Lisp objects. Write it out and read it back in and you'll get an equal object. This is incredibly useful for many things, including debugging, but also makes it easy to envision a protocol for distributed computing - especially when you consider that Lisp programs also consist of Lisp objects.
On the other hand, Lisp's read-write protocol isn't the most efficient as far as parsing and transmission are concerned. So something could be gained there. And not all objects can be read back in - for some it would even be a Bad Thing if they could. And none of the harder problems (like which parts of the graph to send) have been addressed yet. On the gripping hand, I honestly feel it's already better than SOAP.
For the rest, I think the trick is to keep things simple. Think of what you want to send. Encode that using some simple, efficient encoding, and send it. Don't shoot for automagic, Just Works exchange of arbitrary program objects. Think about what you really need to send and send only that.
Oh, and don't draw in layers and layers of frameworks, please.
``you don't get the Nobel prize for an article in "Il sore 24 ore"''
But you do get to the front page of Slashdot!
More seriously, the established journals are often hideously slow in publishing stuff, and often dare to charge you for it, too. In the age of the Internet, all that can be dispensed with. You can get your discoveries and inventions published, peer reviewed, and communicated to the masses, all for free and without having to wait on some organization's release cycle.
You can also, of course, use the Internet to spread lies and misinformation, create fake peer reviews, and communicate all that to the masses, all for free and without having to wait on some organization's release cycle.