As someone already pointed out, security at financial institutions tends to be much better than at ordinary online stores. But in addition to that, in theory, someone obtaining the Amex one-time card customer database wouldn't necessarily have any direct way to profit from that - unless the database included a permanent credit card number (which in theory, it wouldn't necessarily have to), or gave the thief a way to generate bogus one-time numbers (which also shouldn't be possible, in theory.)
In practice, I wouldn't be surprised to find that Amex's database does include the customer's permanent credit card number, but that's an implementation detail. There's no question that any way you look at it, one-time numbers really do add significant security.
there's a sense of humor issue here...
on
Beer In Space
·
· Score: 2
...i.e., you need one. C'mon, relax, forget about your next project deadline for a second, and truly think about the concept of "Beer in Space!" After a while, you might see the point. Of course, it might help if you consume a few beers first yourself...
They should all be programming in a really difficult programming language. How about Intercal? Befunge? Rube? Maelstroem? Dis? Unlambda? BrainF**k?
The truth is, a student capable of learning to actually write code in Unlambda and/or Brainfuck, would have actually had to learn a lot, and would either gain an intuitive understanding of how either Turing machines or the lambda calculus works, or die trying.
After taking the AP exam, though, they'd have to go for post-traumatic stress counseling...
I'm sure exactly the same could be said for lisp, but I hated the lousy stinking language myself;-)
I had something of the same experience after learning LISP in university. More recently, though, I picked up a copy of the famous SICP, and finally "got it" in a way that I never did previously. Sure, I could program in LISP and write code to simulate missionaries and cannibals crossing a river, but I had no real understanding of the principles behind the language. SICP teaches you to program by, in effect, teaching you to write programming languages, complete with real working examples. After working through it, you might still hate all the Irritating Single Parentheses, but LISP (or at least Scheme) will probably seem quite a bit more impressive.
If you've already worked through it, start over!;^)
There's an answer to this: one of the areas in which Java has been succeeding is for development, not of commercial packages for resale, but of business apps for a company's internal use - often the back end of its public web site or intranet). These kind of applications often used to be developed in things like Visual BASIC, or older "4GL" tools like SQLWindows.
Java is actually a pretty good fit in this market, and has been adopted rapidly as a standard by large organizations like banks, insurance companies, etc., because of the promise, on which Java to some extent delivers, of more maintainable, quicker-to-develop code compared to what came before. Among other things, the strong typing probably helps reduce errors on larger projects where programmers are coding to each other's interfaces: it catches all kinds of mistakes at compile time, and also forces programmers to at least minimally "document" (via the code) interfaces in some detail, enforcing a kind of discipline which can be expensive to not have.
At the same time, Java's exposure and ubiquity,
the marketing focus on the JVM as a "platform", and its frequent use for web-server-side processing, has created an attractive standardized environment for all sorts of people to port their systems to, including language vendors, academics, etc.
The bottom line is that Python didn't have a large corporation marketing it at the exact time that a highly portable, VM-based language seemed like a useful solution (how else were people going to animate stuff on their web pages, back in '96?) Sun saw an opportunity and exploited it, and as always, an agreed-upon standard, de facto or otherwise, is a powerful force to reckon with in the marketplace. The large companies adopting it take comfort in the fact that Java, the JVM, and the EJB infrastructure is backed by the likes of Sun and IBM. Python could never have made such inroads in such a short space of time without this kind of commercial backing.
After being cooped up in an apartment through the depression and the war, with no money and rationing, and nothing getting maintained and nothing new getting built for 30 years, a nice shiny Chevrolet and your own federally subsidized 1/2 acre probably sounded pretty good!)
It still does, to me. I grew up in apartments, not during any wars or depressions. I hated it - playing in streets, or on rooftops, surrounded by dirty grey concrete and black asphalt, like some kind of Dickensian or Doctorowian urchins. We later moved into the suburbs, and by comparison that little 1/8th acre seemed like heaven on earth.
Search for Javascript and Brendan on Google and you'll see plenty of references. You're correct that it was originally called LiveScript. Sun and Netscape did a deal at the time Java was being integrated into the Netscape browser, and the scripting language was renamed to convey the its intention of being used to script Java objects within the browser.
As for Microsoft, they just created their own clone, and called it JScript.
I have the same gripe as the original poster - I would have loved to attend, and some advance knowledge of this event would have been nice. Otherwise it's "News for Nerds. Stuff that's obsolete."
Thanks for your work on YRO, BTW! Perhaps you can help enact what the one of the other responses suggested: an "events" section. Magazines do this, why not/.?
IANAA, but this didn't used to be legally justifiable, since at the very least, reading a book aloud would have qualified as "fair use". Nowadays, in the USA, under the DMCA, the concept of fair use has been seriously diluted, and a copyright owner can impose almost any restriction on the use of their work.
In this case, the "work" is apparently having converted a free Project Gutenberg text into a formatted form. Which is interesting, since it could be argued that the text itself is not their work, and thus the only infringement would be verbally describing the look of the layout or fonts...
What is the legitimate relevance to the public of
intermediate election results?
Simple: it allows citizens to make a fully-informed choice about how they
vote. After all, unless you also plan to ban polling prior to the election,
these days people usually have a pretty good idea of how their countrymen are
planning to vote. It's not possible (nor desirable!) to prevent people from
planning their vote strategically. Deliberately withholding information either
before or during an election is unlikely to be beneficial to the overall
process.
This is closely related to your concern about, in
effect, the "anonymity" of an entire state or province's vote.
The availability of intermediate results would allow people even in the earliest
time zones to consider the actions of their fellow citizens when voting.
This isn't a bad thing. In fact, the only reason publicizing intermediate results can be considered bad, is if you've chosen
to attempt to suppress the overall results. One bad
decision leads to another, until the whole package appears somehow inevitable.
In fact, it is inevitable: the result of the initial bad decision
to try to suppress information.
My concern with suppressing information of this kind is this: by encouraging
governments to believe that laws which suppress information are beneficial, and
by encouraging citizens to believe that such laws are benign, we create
paternalistic governments, governments which don't think twice about hiding
information from their citizens, governments that ultimately are
dangerous. Election Canada's actions against Paul Bryan, searching his
apartment, seizing his hard disks, and forcing him to legally defend his
actions, are an example of what I'm talking about.
To justify withholding of information, there has to be a concern of
overriding importance being addressed. National security, for example, is
used as such a justification. But in the case of elections, there is no
such justification. I don't see how it can be argued that knowledge of
voting patterns in other areas is such a threat to a nation's integrity, that
citizens should have their right to communicate with each other curtailed.
As I have briefly argued, I believe the opposite is true: the information is
useful to citizens, and should be made available.
I thought the other reply to your message raised an interesting point about
the effect of the election on the Canadian dollar. This reminded me of another
context in which free information is important: markets. I think one can draw a
parallel between voting and economic markets: the value of your vote, and the
value of a given candidate, doesn't exist in isolation, but rather is highly
dependent on what everyone else is doing. A vote is a resource with value; you
want to utilize that resource in the way that does most good. Just as you might
choose not to buy shares in a company whose share price is plummeting, you might
choose not to vote for a candidate who is losing badly, and instead vote for a
candidate you believe has a chance of winning. This is a valid choice, and it is
not up to governments to withhold this choice from their citizens.
I think you contradict yourself somewhat when on the one hand you say
"The only 'correct' vote is the vote for your conscience, and the only
'wasted' vote is one against it", and on the other hand you say
"The very fact that you don't know how other people are voting forces
you to consider your vote more carefully". Does one's conscience
change because of knowing about other people's votes? Or are you suggesting that
knowing about other people's votes is a "temptation" which leads them
astray from their consciences? And thus, to the conclusion that people cannot be
trusted with the information, which is exactly what disturbs me?
It's commercial and not open source, but VMWare does quite a bit of what you're suggesting:
You can shut down a virtual OS session in mid-operation and restart later from the saved state.
You can do client/server testing on the same box. I test from a Windows NT client to a Linux session running Apache, for example.
OS morphing would require some setup, but it
might be possible to do, even as an end user. As it is, you can have a virtual machine act as either a firewall, or a secure isolated server to the outside world while the host remains hidden, or vice versa: an internal server invisible to the outside world.
Saving state every few minutes could be tricky - the OS would have to suspend all processing while it did that, which probably isn't acceptable in many cases.
I would imagine once Plex86 is fully operational, it should be able to do this stuff too.
There is a reason that polling is private and anonymous, and it isn't a large stretch to extend this from individual votes to intermediate results.
Actually I think that is a large stretch - care to explain why you think otherwise?
Reporting how voting is going, whether based on exit polls or actual counts in some other district, is completely unrelated to the issue of privacy or anonymity. The only way privacy would be compromised is if a live vote count were displayed above each polling booth, or something like that, and that's a big stretch.
You did put your finger on something important, though, which is that privacy does involve restriction of information. There are some unique features about this, though: the information that an individual has a right to keep private is information that affects only that individual, his family & friends etc. As soon as information has legitimate relevance to the public, however, the right to privacy often has to give way to the "public's right to know". In the case of an election, there are clear and obvious reasons why privacy and anonymity are important; but that has nothing to do with the dissemination of aggregate information, as long as that is done without compromising privacy.
Restriction of information on the grounds that "the public can't be trusted to respond 'correctly' " is not the way to achieve a fair society. It smacks of a kind of elitism that might have had some justification a couple of hundred years ago, when the electorate wasn't as well educated, but we would do well to reexamine such assumptions today.
There's a myth being perpetuated in this discussion, which is that somehow it's a bad thing if people find out the election results from a different part of their country, if they haven't yet voted themselves.
This attitude is a largely unexamined hangover from a long, long time ago. When media first started making it possible to communicate election information across countries in short amounts of time, this worried politicians and citizens who were just more comfortable with the way it used to be.
The concern is the alleged danger of people changing their vote, or not voting, as a result of hearing results from somewhere else. However, if a citizen truly has an interest in the government and politics of their country, they are likely to vote anyway, since their are all sort of other reasons to vote than simply to cause the selection of a particular favored politician.
An educated populace should understand this, and vote accordingly, regardless of what they may hear about other parts of the country.
True, the majority of the population in most democratic nations probably don't understand this, but that is either their own fault, or the fault of education. The latter can be corrected by better education about these matters, while the former is easily addressed: I believe it was Michael Moore who, instead of cajoling people to go out and vote, said on TV just prior to the election "If you haven't figured out why it's important to vote yet, please DON'T VOTE!"
As usual in situations where the desire to censor information exists, the underlying flaw in the logic is the assumption that the information should be restricted in the first place.
So why bother with the "{" and "}"? The answer ends up being psychological rather than technical
I disagree. I've worked with both languages, and I hate the fact that in the process of rearranging code in an editor, you have to be careful to avoid losing the indentation. With explicit block markers like {}, this just isn't an issue. So no, it's not just psychological, and won't be until program editors become much more intelligent.
Maybe they are just up to their old trick of trying to do everything their own way - we do C++ better than C++...
In the case of.NET, what MS is really saying is "we do the Java VM better than the Java VM." The core of.NET is a virtual machine which is supposed to provide all the benefits of the JVM with less focus on a single language - and therefore not subject to that one language's limitations.
If you consider the fact that the JVM has been used as a target for an enormous number of other languages, the.NET approach actually makes a lot of technical sense. Interoperability between languages - for example, between a server-side web scripting language and a more heavy-duty back end language - becomes trivial when both languages execute in the same virtual machine. People are already doing this sort of thing to some extent, using things like Rhino (Javascript on the JVM) or Jacl (Tcl in Java) as a scripting environment to invoke heavier-duty Java objects.
This approach isn't completely mainstream at the moment, but it has a lot of benefits. Microsoft has paid attention to these possibilities and is betting their development strategy on it, in the same way as they bet on COM/ActiveX previously.
I suspect this will be very successful amongst loyal MS developers. True, you'd have to be drinking serious amounts of Kool-Aid to be willing to devote development resources to developing in a brand-new language like C#, which because of its origins has little likelihood of gaining the kind of multi-independent-vendor popularity that Java has. But if you already use one of the other languages that support.NET, there's little risk in taking advantage of it if you develop only for MS platforms.
I look forward to seeing open source projects compete in this arena. The JVM opened the door to this, but Sun's proprietary attitude to Java has caused many problems. Either the JVM must be freed from its proprietary roots, or an open source alternative must arise. Either way, open source just makes an incredible amount of sense for such a strategic base platform - as with Linux, it becomes much easier for vendors of any stripe to commit to it.
That "Rocket a Day" plan reminds me of what Craig McCaw et al plan for the Teledesic network. They plan to launch 288 satellites, and McCaw talks about treating it more like a mass-production scenario than has been the case for other satellites and their launches.
This has become quite an interesting situation. Motorola (basically) creates this huge white elephant and finances it by selling shares and bonds during an economic boom. Unfortunately, they did a really bad job, making enough mistakes of both a business and technical nature to prove their collective incompetence beyond a doubt.
Now their space junk is about to come crashing down on Earth, potentially landing on countries with which the U.S. already has difficult diplomatic relations. I mean, accidentally blowing up a Chinese Embassy during a "war" because a CIA Rolodex is out of date is one thing, but crashing a satellite into Beijing would be a completely different story.
If NASA's odds are at all close to reality, is it any wonder that the Department of Defense has stepped in? The next question may be what assurances will need to be in place the next time some company decides it wants to blanket the earth with flying diplomatic disasters. Motorola and its cohorts may have done a great disservice to the cause of commercial space exploitation.
BTW, I should mention that I'm all for ambitious ventures involving science, space, and/or technology. I just wish that the people with the bucks weren't so catastrophically dumb sometimes!
I don't think I made my point very well. My point is that kernel size alone is not a sufficient criterion on which to judge an OS. The original message said that Win2K was "just wrong" to use more than 15MB of kernel memory.
I don't know or care whether Win2K is a good OS, but I don't agree that one can judge it on the basis of the size of its kernel alone. If it uses a different architecture, the kernel size may make sense in its context. Kneejerk "15MB is too big" reactions tend to relate more to currently assumed limitations, than to anything real.
The flaw in your thinking is the fallacy that more "technological progress" in operating systems requires more non-pagable kernel memory.
I didn't mean to imply that. I'm not saying that progress does or doesn't lie that way; only that it doesn't make sense to close off a particular direction for no good reason.
Perhaps message-passing microkernels will ultimately replace monolithic kernels, for example, but until that's actually happened (and Linux is a famous argument to the contrary), there may be real benefits to be had by including major additional functionality in a kernel. This kernel ORBit implementation is a good example: it's not so far fetched that in a few years time, an ORB in the kernel will be seen as a necessity.
It also isn't much of a stretch to imagine an OS built on top of an ORB (which in some respects, isn't that different from a message-passing microkernel model.) If that approach were desirable, the route from here to there might very well be to start out by building the ORB into the kernel, then slowly removing other basic services from the kernel and replacing them with external object implementations. (I can imagine a lot of knees jerking right around now.) Making such radical changes, however, doesn't happen easily when people allow arbitrary metrics to define the boundary of their world.
That's fine, and I don't really disagree - my point just was that I don't think it's valid to say that "a kernel which takes up 15MB is wrong".
In any case, assuming the monolithic kernel survives the next decade or so, it's only a matter of time before ORBs, virtual machines and god knows what else make it in there, because everyone will be using them. The 90MB kernel isn't that far off, mark my words!;)
I hope you're not suggesting we embed the JRE into the kernel! That would be grotesque, despite the niftiness... No! No niftiness! Don't tempt me! Back!
Heh!
But you've got it wrong - don't embed the JRE in the kernel. Rather, build the kernel on top of a VM. Of course, it would have to be a better VM than the JRE, otherwise you'd just end up with JavaOS - it would need better support for low-level operations, and a number of performance issues would have to be addressed - e.g. support for offset-based method dispatch a la C++ vtables, in addition to the more dynamic runtime lookup (for all I know, MS.NET does this - scary thought.)
When, in a few years time, you're running a 2GHz Crusoe using its native microcode with 1GB of post-Rambus high-bandwidth RAM, hooked to the Internet over gigabit fiber, this won't seem so farfetched.
It's scary, Win2K uses more than 15MB of non-pagable kernel memory. That's just wrong.
Regardless of what Win2K does, I have a problem with this idea of impeding technological progress by placing arbitrary limits on something like kernel size. Why is 15MB bad while some lesser amount is OK? All you're really saying is that from an economic perspective, right now, you consider that OS's should require less RAM for their kernel. Back in 1985, you would have presumably been criticising any OS that took up more than say 100K of memory, and I would have been similarly pointing out the flaw in your thinking.
Don't fall into the trap of spouting variations on the statement "640K should be enough for anyone!" (alleged Bill Gates quote.)
I understand where you're coming from, although I know people who run ISPs who haven't had to resort to this sort of thing, but then I don't know your particular situation.
I have a question about this port-blocking business: what, exactly, does it protect your company from? If a user is using you as an ISP to connect to somebody else's insecure mail server, isn't the problem with that mail server? If the problem is volume of outgoing data that a user is sending, I would think that's something you should be able to control separately.
I have much less of a problem with something like the MAPS RBL than I do with blanket blocking of ports. MAPS punishes the actual behavior of individuals and companies, whereas you're punishing everybody in advance, even if they don't know it: guilty until proven innocent.
Slashdot Mirror
In practice, I wouldn't be surprised to find that Amex's database does include the customer's permanent credit card number, but that's an implementation detail. There's no question that any way you look at it, one-time numbers really do add significant security.
...i.e., you need one. C'mon, relax, forget about your next project deadline for a second, and truly think about the concept of "Beer in Space!" After a while, you might see the point. Of course, it might help if you consume a few beers first yourself...
The truth is, a student capable of learning to actually write code in Unlambda and/or Brainfuck, would have actually had to learn a lot, and would either gain an intuitive understanding of how either Turing machines or the lambda calculus works, or die trying.
After taking the AP exam, though, they'd have to go for post-traumatic stress counseling...
I had something of the same experience after learning LISP in university. More recently, though, I picked up a copy of the famous SICP, and finally "got it" in a way that I never did previously. Sure, I could program in LISP and write code to simulate missionaries and cannibals crossing a river, but I had no real understanding of the principles behind the language. SICP teaches you to program by, in effect, teaching you to write programming languages, complete with real working examples. After working through it, you might still hate all the Irritating Single Parentheses, but LISP (or at least Scheme) will probably seem quite a bit more impressive.
If you've already worked through it, start over! ;^)
Java is actually a pretty good fit in this market, and has been adopted rapidly as a standard by large organizations like banks, insurance companies, etc., because of the promise, on which Java to some extent delivers, of more maintainable, quicker-to-develop code compared to what came before. Among other things, the strong typing probably helps reduce errors on larger projects where programmers are coding to each other's interfaces: it catches all kinds of mistakes at compile time, and also forces programmers to at least minimally "document" (via the code) interfaces in some detail, enforcing a kind of discipline which can be expensive to not have.
At the same time, Java's exposure and ubiquity, the marketing focus on the JVM as a "platform", and its frequent use for web-server-side processing, has created an attractive standardized environment for all sorts of people to port their systems to, including language vendors, academics, etc.
The bottom line is that Python didn't have a large corporation marketing it at the exact time that a highly portable, VM-based language seemed like a useful solution (how else were people going to animate stuff on their web pages, back in '96?) Sun saw an opportunity and exploited it, and as always, an agreed-upon standard, de facto or otherwise, is a powerful force to reckon with in the marketplace. The large companies adopting it take comfort in the fact that Java, the JVM, and the EJB infrastructure is backed by the likes of Sun and IBM. Python could never have made such inroads in such a short space of time without this kind of commercial backing.
It still does, to me. I grew up in apartments, not during any wars or depressions. I hated it - playing in streets, or on rooftops, surrounded by dirty grey concrete and black asphalt, like some kind of Dickensian or Doctorowian urchins. We later moved into the suburbs, and by comparison that little 1/8th acre seemed like heaven on earth.
As for Microsoft, they just created their own clone, and called it JScript.
Thanks for your work on YRO, BTW! Perhaps you can help enact what the one of the other responses suggested: an "events" section. Magazines do this, why not /.?
In this case, the "work" is apparently having converted a free Project Gutenberg text into a formatted form. Which is interesting, since it could be argued that the text itself is not their work, and thus the only infringement would be verbally describing the look of the layout or fonts...
Simple: it allows citizens to make a fully-informed choice about how they vote. After all, unless you also plan to ban polling prior to the election, these days people usually have a pretty good idea of how their countrymen are planning to vote. It's not possible (nor desirable!) to prevent people from planning their vote strategically. Deliberately withholding information either before or during an election is unlikely to be beneficial to the overall process.
This is closely related to your concern about, in effect, the "anonymity" of an entire state or province's vote. The availability of intermediate results would allow people even in the earliest time zones to consider the actions of their fellow citizens when voting. This isn't a bad thing. In fact, the only reason publicizing intermediate results can be considered bad, is if you've chosen to attempt to suppress the overall results. One bad decision leads to another, until the whole package appears somehow inevitable. In fact, it is inevitable: the result of the initial bad decision to try to suppress information.
My concern with suppressing information of this kind is this: by encouraging governments to believe that laws which suppress information are beneficial, and by encouraging citizens to believe that such laws are benign, we create paternalistic governments, governments which don't think twice about hiding information from their citizens, governments that ultimately are dangerous. Election Canada's actions against Paul Bryan, searching his apartment, seizing his hard disks, and forcing him to legally defend his actions, are an example of what I'm talking about.
To justify withholding of information, there has to be a concern of overriding importance being addressed. National security, for example, is used as such a justification. But in the case of elections, there is no such justification. I don't see how it can be argued that knowledge of voting patterns in other areas is such a threat to a nation's integrity, that citizens should have their right to communicate with each other curtailed. As I have briefly argued, I believe the opposite is true: the information is useful to citizens, and should be made available.
I thought the other reply to your message raised an interesting point about the effect of the election on the Canadian dollar. This reminded me of another context in which free information is important: markets. I think one can draw a parallel between voting and economic markets: the value of your vote, and the value of a given candidate, doesn't exist in isolation, but rather is highly dependent on what everyone else is doing. A vote is a resource with value; you want to utilize that resource in the way that does most good. Just as you might choose not to buy shares in a company whose share price is plummeting, you might choose not to vote for a candidate who is losing badly, and instead vote for a candidate you believe has a chance of winning. This is a valid choice, and it is not up to governments to withhold this choice from their citizens.
I think you contradict yourself somewhat when on the one hand you say "The only 'correct' vote is the vote for your conscience, and the only 'wasted' vote is one against it", and on the other hand you say "The very fact that you don't know how other people are voting forces you to consider your vote more carefully". Does one's conscience change because of knowing about other people's votes? Or are you suggesting that knowing about other people's votes is a "temptation" which leads them astray from their consciences? And thus, to the conclusion that people cannot be trusted with the information, which is exactly what disturbs me?
- You can shut down a virtual OS session in mid-operation and restart later from the saved state.
- You can do client/server testing on the same box. I test from a Windows NT client to a Linux session running Apache, for example.
- OS morphing would require some setup, but it
might be possible to do, even as an end user. As it is, you can have a virtual machine act as either a firewall, or a secure isolated server to the outside world while the host remains hidden, or vice versa: an internal server invisible to the outside world.
Saving state every few minutes could be tricky - the OS would have to suspend all processing while it did that, which probably isn't acceptable in many cases.I would imagine once Plex86 is fully operational, it should be able to do this stuff too.
Actually I think that is a large stretch - care to explain why you think otherwise?
Reporting how voting is going, whether based on exit polls or actual counts in some other district, is completely unrelated to the issue of privacy or anonymity. The only way privacy would be compromised is if a live vote count were displayed above each polling booth, or something like that, and that's a big stretch.
You did put your finger on something important, though, which is that privacy does involve restriction of information. There are some unique features about this, though: the information that an individual has a right to keep private is information that affects only that individual, his family & friends etc. As soon as information has legitimate relevance to the public, however, the right to privacy often has to give way to the "public's right to know". In the case of an election, there are clear and obvious reasons why privacy and anonymity are important; but that has nothing to do with the dissemination of aggregate information, as long as that is done without compromising privacy.
Restriction of information on the grounds that "the public can't be trusted to respond 'correctly' " is not the way to achieve a fair society. It smacks of a kind of elitism that might have had some justification a couple of hundred years ago, when the electorate wasn't as well educated, but we would do well to reexamine such assumptions today.
This attitude is a largely unexamined hangover from a long, long time ago. When media first started making it possible to communicate election information across countries in short amounts of time, this worried politicians and citizens who were just more comfortable with the way it used to be.
The concern is the alleged danger of people changing their vote, or not voting, as a result of hearing results from somewhere else. However, if a citizen truly has an interest in the government and politics of their country, they are likely to vote anyway, since their are all sort of other reasons to vote than simply to cause the selection of a particular favored politician.
An educated populace should understand this, and vote accordingly, regardless of what they may hear about other parts of the country.
True, the majority of the population in most democratic nations probably don't understand this, but that is either their own fault, or the fault of education. The latter can be corrected by better education about these matters, while the former is easily addressed: I believe it was Michael Moore who, instead of cajoling people to go out and vote, said on TV just prior to the election "If you haven't figured out why it's important to vote yet, please DON'T VOTE!"
As usual in situations where the desire to censor information exists, the underlying flaw in the logic is the assumption that the information should be restricted in the first place.
Does being "willing to look at the big picture" also require a willingness to make sweeping generalizations, both explicit and implied?
I disagree. I've worked with both languages, and I hate the fact that in the process of rearranging code in an editor, you have to be careful to avoid losing the indentation. With explicit block markers like {}, this just isn't an issue. So no, it's not just psychological, and won't be until program editors become much more intelligent.
In the case of .NET, what MS is really saying is "we do the Java VM better than the Java VM." The core of .NET is a virtual machine which is supposed to provide all the benefits of the JVM with less focus on a single language - and therefore not subject to that one language's limitations.
If you consider the fact that the JVM has been used as a target for an enormous number of other languages, the .NET approach actually makes a lot of technical sense. Interoperability between languages - for example, between a server-side web scripting language and a more heavy-duty back end language - becomes trivial when both languages execute in the same virtual machine. People are already doing this sort of thing to some extent, using things like Rhino (Javascript on the JVM) or Jacl (Tcl in Java) as a scripting environment to invoke heavier-duty Java objects.
This approach isn't completely mainstream at the moment, but it has a lot of benefits. Microsoft has paid attention to these possibilities and is betting their development strategy on it, in the same way as they bet on COM/ActiveX previously.
I suspect this will be very successful amongst loyal MS developers. True, you'd have to be drinking serious amounts of Kool-Aid to be willing to devote development resources to developing in a brand-new language like C#, which because of its origins has little likelihood of gaining the kind of multi-independent-vendor popularity that Java has. But if you already use one of the other languages that support .NET, there's little risk in taking advantage of it if you develop only for MS platforms.
I look forward to seeing open source projects compete in this arena. The JVM opened the door to this, but Sun's proprietary attitude to Java has caused many problems. Either the JVM must be freed from its proprietary roots, or an open source alternative must arise. Either way, open source just makes an incredible amount of sense for such a strategic base platform - as with Linux, it becomes much easier for vendors of any stripe to commit to it.
...it affects the majority of /. readers who attempt to visit the second link mentioned in the article.
As in "accidentally" blew up the embassy. But thanks for the update, I hadn't heard that explanation.
That "Rocket a Day" plan reminds me of what Craig McCaw et al plan for the Teledesic network. They plan to launch 288 satellites, and McCaw talks about treating it more like a mass-production scenario than has been the case for other satellites and their launches.
Now their space junk is about to come crashing down on Earth, potentially landing on countries with which the U.S. already has difficult diplomatic relations. I mean, accidentally blowing up a Chinese Embassy during a "war" because a CIA Rolodex is out of date is one thing, but crashing a satellite into Beijing would be a completely different story.
If NASA's odds are at all close to reality, is it any wonder that the Department of Defense has stepped in? The next question may be what assurances will need to be in place the next time some company decides it wants to blanket the earth with flying diplomatic disasters. Motorola and its cohorts may have done a great disservice to the cause of commercial space exploitation.
BTW, I should mention that I'm all for ambitious ventures involving science, space, and/or technology. I just wish that the people with the bucks weren't so catastrophically dumb sometimes!
I don't know or care whether Win2K is a good OS, but I don't agree that one can judge it on the basis of the size of its kernel alone. If it uses a different architecture, the kernel size may make sense in its context. Kneejerk "15MB is too big" reactions tend to relate more to currently assumed limitations, than to anything real.
The flaw in your thinking is the fallacy that more "technological progress" in operating systems requires more non-pagable kernel memory.
I didn't mean to imply that. I'm not saying that progress does or doesn't lie that way; only that it doesn't make sense to close off a particular direction for no good reason.
Perhaps message-passing microkernels will ultimately replace monolithic kernels, for example, but until that's actually happened (and Linux is a famous argument to the contrary), there may be real benefits to be had by including major additional functionality in a kernel. This kernel ORBit implementation is a good example: it's not so far fetched that in a few years time, an ORB in the kernel will be seen as a necessity.
It also isn't much of a stretch to imagine an OS built on top of an ORB (which in some respects, isn't that different from a message-passing microkernel model.) If that approach were desirable, the route from here to there might very well be to start out by building the ORB into the kernel, then slowly removing other basic services from the kernel and replacing them with external object implementations. (I can imagine a lot of knees jerking right around now.) Making such radical changes, however, doesn't happen easily when people allow arbitrary metrics to define the boundary of their world.
In any case, assuming the monolithic kernel survives the next decade or so, it's only a matter of time before ORBs, virtual machines and god knows what else make it in there, because everyone will be using them. The 90MB kernel isn't that far off, mark my words! ;)
Heh!
But you've got it wrong - don't embed the JRE in the kernel. Rather, build the kernel on top of a VM. Of course, it would have to be a better VM than the JRE, otherwise you'd just end up with JavaOS - it would need better support for low-level operations, and a number of performance issues would have to be addressed - e.g. support for offset-based method dispatch a la C++ vtables, in addition to the more dynamic runtime lookup (for all I know, MS .NET does this - scary thought.)
When, in a few years time, you're running a 2GHz Crusoe using its native microcode with 1GB of post-Rambus high-bandwidth RAM, hooked to the Internet over gigabit fiber, this won't seem so farfetched.
Regardless of what Win2K does, I have a problem with this idea of impeding technological progress by placing arbitrary limits on something like kernel size. Why is 15MB bad while some lesser amount is OK? All you're really saying is that from an economic perspective, right now, you consider that OS's should require less RAM for their kernel. Back in 1985, you would have presumably been criticising any OS that took up more than say 100K of memory, and I would have been similarly pointing out the flaw in your thinking.
Don't fall into the trap of spouting variations on the statement "640K should be enough for anyone!" (alleged Bill Gates quote.)
I have a question about this port-blocking business: what, exactly, does it protect your company from? If a user is using you as an ISP to connect to somebody else's insecure mail server, isn't the problem with that mail server? If the problem is volume of outgoing data that a user is sending, I would think that's something you should be able to control separately.
I have much less of a problem with something like the MAPS RBL than I do with blanket blocking of ports. MAPS punishes the actual behavior of individuals and companies, whereas you're punishing everybody in advance, even if they don't know it: guilty until proven innocent.