What chance does a competitor to GCC have on a Linux based OS? None... C compilation is basically a solved problem.
Tell that to all the people dropping hundreds of dollars for a GOOD optimizing complier (icc is $399 commercial, free non-commercial).
My point is not to be an ad. My point is that free stuff is worth what you pay for it, and when you need quality, you get out the checkbook and pay someone. VMware had most of Xen's features four years ago, and most of the difference are things VMware has invented since then. We're in for some fun times, because BOTH VMware and Xen are going to be pushing things forward, and WE benefit.
Actually, it's some asshole LINUX developer to blame for the unresponsiveness... some genuius decided X servers should run with a high priority. Great for responsiveness on native hardware, but kills anyone on the host because now a guest uses 100% cpu just idling.
Re: graphics, no one has figured out a good way to accelerate the graphics interface yet. But the money in virtualization now is in SERVER virtualization, where gfx don't matter one bit.
I don't believe it for a second. While this statement may be facutally true, in real life where disk and network IO matter more than percentage CPU overhead, this statement is mightily misleading.
The point is that CPU overhead is irrelevant. And everyone doing this is learning (quickly) to paravirtualize their disk and network activity. VMware Workstation doesn't have either, but the server models are more advanced and do. Actually, properly virtualized I/O subsystems are much faster than hardware - no limitations of real Ethernet, so transmitting 10MB of info can be done with a few page table tweaks instead of across a wire.
Well - with separation (i.e. jails) the one system kernel will optimize (cache inodes, share code memory pages, etc) across ALL contexts (or jails). This is something VMWare/Xen/etc simply cannot do by design because a guest kernel cannot have access to the host's cache.
cache inodes: irrelevant, if you're running different OSes then you're on different filesystems.
share code memory pages : VMware started doing this three or four years ago. They got a Best Paper out of it... 2002 OSDI I think? The biggest gain is sharing zeroed-pages - those can even be shared cross-OS.
The fundamental problem of separation (jails / zones) is the COMPLEXITY it adds to the operating system. It's hard to get right - really hard. I'll bet you good money there are bugs in all the existing separation code out there. With virtualization, you just have to get the virtualizing layer correct; with separation, the existing OS has to be correct, PLUS the new code... yeah right.
And with vmware 5 you can make clones of the machines that are basically live diff's.
I think QEMU and Bochs do this just as well.
I don't know about Qemu (I doubt it). Bochs didn't as of a year and a half ago. Somebody might have added it to Bochs since then (and the somebody, he works for VMware...). Anyway, making clones is easy, just copy-on-write. Keeping clones in a space-efficient manner is trickier, and VMware refused to release the multiple-checkpoint implementation until it was efficient.
So, if two people tell me negative information, I'll know more?
Depends on what you're doing. (-2)+(-3)=+1 is Slashdot Moderator Math, which has no basis in either reality or fantasy and transmits no useful information whatsoever.
Are C++ backers intentionally trying to miss the point? The post was about human factors.
Nope - you are over-simplifying the language. Really. C++ is already as simple as possible without sacraficing power. By trying to portray it as simpler, you conveniently create straw-man arguments that just aren't true.
You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose?
"::" is necessary. In C++ there are many ways of naming a function, and three symbols. "->" means call through a vtable. "." means call through static dispatch. "::" names a specific version - a concept orthagonal to calling. (Ever tried calling a specific parent version of a function in Java? It's a lot harder than in C++, and I have a very good reason to do that two or three times a year). Don't assume C++ has Java's over-simplified version of OOP; C++ is much more powerful (albeit harder to use!)
Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV?
You expect a 1995-grade compiler back in 1985? Fine, while you're at it, can you complain about LPs, I'd like those to be standard again too... The point is, when C++ was born, that BNF was too hard to write outside of academia, and it took those extra ten years before computers and compilers that could handle it were available.
Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?
Your definition of "basic functionality", not mine. I'm quite happy writing code without cramping my style around garbage collectors. I'm not demanding you stop using GC, so I'd appreciate it if you stop demanding that I must use GC. I find GC moronic, I can manage memory perfectly well on my own thank you (I learned it very well while becoming a kernel programmer).
"cin >> s, shift right or method call?"
Method call....(e.g. if 'cin' in your example isn't a stream.)
Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise.
He's exactly right. "cin" always means "character input stream", just like Java's "clone" always means "deep copy of an object" or C's "errno" always means "error number".
Bjarne says that "a * b" for matrix multiply and "a b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.
Me, I blame the fool who thought a string should be a 1xN matrix and got slap-happy with automatic type conversions. Operator overloading is a way for a programmer to make semantic conventions that are blindingly obvious be reflected that way in the code; they are not a tool to hide programmer laziness. And unnecessary typecasts are a sign of poor design and laziness (a programmer problem), and not a problem with the underlying language.
C++ ain't a perfect language. But I like the power of C++. If you don't appreciate that power, fine... but realize there are a lot of people out there who do, and your uninformed criticism doesn't dampen my love of C++ in the slightest.
And frankly, what is the benefit of altering the core source? I can't think any, and I'd love to hear a legitimate reason. Well, I can think of one... to wipe out the work of the original authors, which seems to be what the GPL zealots want but that, ironically, goes completely against the principles of the GPL!
Emulation: 300x slowdown.
Dynamic translation: 25x slowdown.
Dynamic translation with aggressive caching: 2-5x slowdown.
Google for Qemu - it's an open-source program that does sparc to x86 dynamic translation, with a 5-10x slowdown.
Dynamic translation does not decode the opcode on each instruction - it would be very expensive, and in fact more expensive than your description suggests. Dynamic translation instead recompiles one instruction set into another instruction set, much like a Java VM translates java bytecode into machine executable. (In fact, exactly like... they use the same JIT optimizations).
But I digress... the reason to not emulate UltraSPARC is because of the hardware. Sparcs have fantastic caches and good bus performance compared to x86 CPUs, they have much better performance monitoring (e.g. counting TLB misses and the like), and a superior ISA that makes many performance-critical tasks (like context switching) cheaper. Opterons (and, notably, NOT Intel's 64 bit offerings) go a long way towards catching up on the raw performance metric, but they still aren't up to par - mostly because they don't scale beyond about 8 processors well, and Opterons use raw MHz to make up for other processor deficiencies.
You are confusing two different types of virtualization. UML is "paravirtualization", it runs an entire (redundant) operating system under virtualization. Easier to implement, but more overhead. Solaris Zones partitions the operating system - that is, it virtualizes at the "init" level. Nobody else does this. The advantage: Solaris only needs one heavyweight kernel floating around.
And yes, technically, the grandparent is incorrect, zones do not provide kernel isolation. Recall the debates about the difference between a kernel (e.g. Linux) and an operating system (e.g. GNU/Linux)? Same here - Solaris Zones virtualizes the operating system (e.g. the GNU-equivalent pieces) without virtualizing the kernel (e.g. Linux). UML virtualizes everything (GNU/Linux). Zones has a lower overhead than UML, and allows better utilization of system resources.
UML is (comparatively) easy. Zones is hard, because you have to have a very robust kernel to make it work. Linux will never have Zones because the core Linux hackers (Torvalds included) would never tolerate the scale of changes needed to put the support Zones needs into a kernel. Thus, Linux will have to subsist on high-overhead programs like UML. Linux is by hobbyists, for hobbyists... and it shows.
And you hit the 100K write limit for a flash device, and BANG your disk is dead.
Swap and temp are the most active parts of your disk! The last thing you want is to hammer the same bytes of memory with write after write after write. Regular data on a flash drive, great; swap, stupid.
As a very recent "kid" myself, I'm so glad you're willing to plan out my entire life. I'm so glad you can be judge, jury, and executioner because of your intensive knowledge of my personal high school experience. I'm so glad you know my hopes and desires better than I do when you've never met me.
Here's one of the things I learned in high school: how to understand a person's motivations through his writing. Allow me to take a swing at yours? You write describing "kids" as second-class citizens to be ignored until sufficiently mature to become... you. Sorry, friend, but I don't want to be you.
However this says nothing about whether they can track the motion of the car itself especially on public roads, it just limits them from searching what is in the car.
My opinion is that the tracking process is the check on the whole system. It takes effort to follow someone - yeah, four cops can probably reconstruct where you are every hour of every day, but the cops have better things to do than watch Joe Citizen. If Joe Citizen really were a concern, the cops should get a warrent - THEN this GPS makes sense.
The information about where you are is public - you can't hide it. But hiding a GPS on you is tantamount to self-incrimination - the GPS is broadcasting your location. There is a world of difference between spending a cop's time and effort following a person, and dropping a bug once and receiving a complete report about where a person goes. The information is the same; the effort required is vastly different. And a GPS transmitter crosses the line between passive surveillance and active interrogation.
our constitution says nothing about a right to privacy, the only privacy is that which is granted by individual laws
Read Amendments 9 and 10, if you want an explicit right to privacy. Those amendments were added specifically to prevent some joker from making up new government powers - which this police department tried. The Supreme Court specifically recognizes an "expectation of privacy" (I believe the case involved intrusive and obscene mail, and the right to not have to see it). The justification is Amendment 9 (or 10, I forget which) and the general trend of privacy preservation in the first ten amendments (assembly, search and seizure, quartering soldiers, etc.). So yes, Americans do enjoy a right to privacy. The right is not nearly so strong as, for example, the right to free speech, but privacy is a recognized right. And it's in constitutional law, which trumps any act of Congress or any other government.
No, because the parking ticket is a legal document issued via "due process". You can of course contest this process (by going to court to fight the fine), but most parking tickets truly are violations.
A single interested ADDer can do 10 persons work in short time. You just have to make sure that someone else take[s] over when it gets repetitive and move the ADDer to another project that he/she [is] interested in.
Translation: Let an ADD-superman do all the interesting work at your company, and make the rest of the peons do the drudge work.
Thinking you can do 10 times the work of someone else? That's not intelligence... that's arrogance. General culture doesn't hate ADD or goth/punk subculture - hate is for the superiority complex that so many denizens of that subculture adopt.
The REAL problem here is that a virus can turn of AV software. So you'd like to make OSS so complex that only a few people can use it, just because some numbskull at MS can't stop a virus from turning off the antivirus?
Defense in depth. Malicious code should never be able to compromise your system in the first place, and we shouldn't bend over backwards preventing malicious code when it's perfectly acceptable to run malicious code (hint: Java's sandbox does it right). It is far, far easier to prevent malicious actions than to prevent all malicious code.
Do you really think that my mom is really going to go through the trouble of downloading a text file (which does not end in.txt), opening it, using a tool that generates an MD5 signature (and that does not come standard on Windows) and comparing strings of 32 characters?
Doesn't matter. Fact is, if even 0.1% of the downloaders check, any compromised original will be detected in just a matter of minutes - hours at the worst. Mother at home will grab it... then the media the next day will loudly announce the problem, the antivirus companies will tear the binary apart and release updated signatures in a few days, and her virus scanner will tell her about the problem in about a week. This does assume she runs a virus scanner... but if she doesn't, she's probably compromised already.
What the Slashdot crowd seems to be missing is that we don't need everyone to follow the MD5 signature. We just need an informed and vocal minority - e.g. Slashdotters - to detect the problem and pick up the pieces afterwards.
4-5 hours? My dorm's been playing the past four WEEKS!!!
And the Evil Turkish Empire is about to learn what happens when he crosses both Russia and Austria every turn for two game years... we finally got him flanked!
Why doesn't sun want the code from solaris transfered to linux?
Sun's not afriad of that... Sun's afraid of the other direction not working. For example... say Solaris has whiz-bang feature A. Some eager developer ports A to Linux. Some better developer makes A v1.1, with some bug fixes and interesting new features. Everyone decides A v1.1 is really cool... except Sun, which can't bring the code back into Solaris because it's GPL and OpenSolaris isn't.
Basically, it's a license that permits redistribution, but always permits Sun to fold back code changes into a proprietary Solaris product. Kinda like StarOffice & OpenOffice...
You conveniently ignore one very important point: patches against a big GPL codebase are WORTHLESS without the rest of that codebase.
Yeah, I can write a patch to the linux kernel (or any other GPL project) and license it however I want. But for anyone to make use of my patch, they'll have to make use of GPLed code as well - what, you expect me to believe that my patch will cleanly apply to the BSD kernel?
If an author contributes code to a large GPL codebase, he is de facto required to GPL it. Sure he can release it under some other license; however, to make use of it, everyone else will have to apply it to the original GPLed code, which immediately brings it back under the GPL. The author has your so-called freedom in name only, but can never make use of that freedom; in my book, that means the author is just as restricted as the GPL.
The GPL limits the licenses YOU can put on OTHER PEOPLE'S WORK
Let me point out again: an author's work is worthless without the GPL code that the work modifies. Thus, the author must de facto release his code under the GPL - thus, the GPL is viral. I am reminded of a Henry Ford quote: "You can choose any color. As long as it's black."
The GPL is a great license... for anyone who believes all code should be GPL. For everyone else, it's just as bad as a Microsoft EULA.
Before you respond, answer this question: What benefit would Sun get from releasing OpenSolaris under the GPL instead of this MPL-clone? Not what advantage YOU get... I'm asking what advantage Sun gets.
If the GPL is so wonderful, why isn't everyone using it? Why did Apache, Apple, Mozilla, and everyone else need to release some other license?
I'm not claiming the GPL is evil. (Nor, in fact, am I claiming Microsoft's EULA's are evil). I am claiming that the GPL is overused, that too many GPL advocates see "Open Source" and assume GPL the complain when it's not GPL, when Open Source actually encompasses a far broader range of licenses.
If you read the license... it's the MPL. That's right, the Mozilla Public License. Looking at the diff version, they went through and changed a bunch of wording (e.g. "Code" -> "Software").
IANAL, but the only significant (to me, at least) difference I saw is Sun retains for themselves the authority to release the code under another license in the future.
My interpretation: they want to make sure that any code someone adds to OpenSolaris can still be distributed by Sun as closed Solaris. Too many GPL zealots would love to cripple Sun by adding GPLed code to OpenSolaris and thereby prevent Sun from distributing closed-source products, so I think this is a pretty reasonable addition. To any GPL zealot out there: most of us don't believe the GPL is manna from heaven, but rather view it like Microsoft: attempting to monopolize and homogenize the software market under one distribution scheme. I'm pleased to see Sun trying to find a way to release code without pandering to the GPL mob.
Now, for those not paying attention, let me repeat myself ONE MORE TIME.
It's the MPL
It's the MPL
It's the MPL
It's the MPL. Got that?
... because the last time a friend and I tried to come up with the best video game characters of all time, it became this birthday present. And this artist is a very busy person who ought not be obliged to make me another one!
The careful Slashdotter who actually follows links will immediately discover my two opinions on the matter.
I can't find anything specifically to this effect, but my guess is that the Efficeon simply doesn't support SMP (they sure don't claim SMP support anywhere). Which means: no cache coherency hardware support and no multiprocessor synchronization primitives in hardware, making shared memory multiprocessing impossible.
Since the chip thus can't be used in a shared-memory configuration, a cluster is ideal. (And frankly, a better use of resources than cramming SMP chips like modern x86 into single-processor boxes and clustering those like the latest Linux-cluster-of-the-month).
Honestly - the system is brilliant. With one catch: the paraniod side of me sees some purchasing department comparing one of these, and a similar Sun workstation, then buying this one because "it has more CPU power". Yes... if you run an app that works over a cluster. If it's a shared memory app, the Sun/SGI/IBM/whoever workstation will leave this one in the dust.
I see one very immediate use for these machines: developing cluster applications! Apps that run on 500-way clusters really do need to be tested on smaller clusters before they consume expensive cluster time - this machine is PERFECT for such testing! Or at least, far better than anything else out there...
In x86 land the 486 was also the first to have a cache. (8kb)
I thought I had a 386SX that had cache - not onboard, but soldered onto the motherboard. Or maybe I'm thinking of another machine. Alas, I don't have the system or the specs anymore, so I can't be sure.
re:FSB, I shouldn't have claimed pathological cases. The fact is, the x86 architecture is very well suited to scale up to multiple CPUs even in leiu of the FSB's limitations - and the grandparent seemed to imply otherwise. Now, a slow FSB has some interesting pathologies, but the general case performance, with good caching, is actually pretty good!
I'm actually quite impressed at how much performance system architects have gotten out of modern processors even given the slow FSBs - with appropriate caching, prefetching, and upcoming multi-core designs (I'm actually looking to the 8-core Niagra as a better example), the FSB's speed is becoming less and less of a bottleneck.
Slashdot Mirror
Tell that to all the people dropping hundreds of dollars for a GOOD optimizing complier (icc is $399 commercial, free non-commercial).
My point is not to be an ad. My point is that free stuff is worth what you pay for it, and when you need quality, you get out the checkbook and pay someone. VMware had most of Xen's features four years ago, and most of the difference are things VMware has invented since then. We're in for some fun times, because BOTH VMware and Xen are going to be pushing things forward, and WE benefit.
Re: graphics, no one has figured out a good way to accelerate the graphics interface yet. But the money in virtualization now is in SERVER virtualization, where gfx don't matter one bit.
The point is that CPU overhead is irrelevant. And everyone doing this is learning (quickly) to paravirtualize their disk and network activity. VMware Workstation doesn't have either, but the server models are more advanced and do. Actually, properly virtualized I/O subsystems are much faster than hardware - no limitations of real Ethernet, so transmitting 10MB of info can be done with a few page table tweaks instead of across a wire.
Well - with separation (i.e. jails) the one system kernel will optimize (cache inodes, share code memory pages, etc) across ALL contexts (or jails). This is something VMWare/Xen/etc simply cannot do by design because a guest kernel cannot have access to the host's cache.
cache inodes: irrelevant, if you're running different OSes then you're on different filesystems.
share code memory pages : VMware started doing this three or four years ago. They got a Best Paper out of it ... 2002 OSDI I think? The biggest gain is sharing zeroed-pages - those can even be shared cross-OS.
The fundamental problem of separation (jails / zones) is the COMPLEXITY it adds to the operating system. It's hard to get right - really hard. I'll bet you good money there are bugs in all the existing separation code out there. With virtualization, you just have to get the virtualizing layer correct; with separation, the existing OS has to be correct, PLUS the new code ... yeah right.
And with vmware 5 you can make clones of the machines that are basically live diff's.
I think QEMU and Bochs do this just as well.
I don't know about Qemu (I doubt it). Bochs didn't as of a year and a half ago. Somebody might have added it to Bochs since then (and the somebody, he works for VMware...). Anyway, making clones is easy, just copy-on-write. Keeping clones in a space-efficient manner is trickier, and VMware refused to release the multiple-checkpoint implementation until it was efficient.
Depends on what you're doing. (-2)+(-3)=+1 is Slashdot Moderator Math, which has no basis in either reality or fantasy and transmits no useful information whatsoever.
YES, when those retarded coders write the specs for the standard libraries (namely, the Java Class Libraries).
C'mon, that's the whole point, the standard library's specs are the language...
I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know.
If they're part of the core libraries, sure!
Nope - you are over-simplifying the language. Really. C++ is already as simple as possible without sacraficing power. By trying to portray it as simpler, you conveniently create straw-man arguments that just aren't true.
You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose?
"::" is necessary. In C++ there are many ways of naming a function, and three symbols. "->" means call through a vtable. "." means call through static dispatch. "::" names a specific version - a concept orthagonal to calling. (Ever tried calling a specific parent version of a function in Java? It's a lot harder than in C++, and I have a very good reason to do that two or three times a year). Don't assume C++ has Java's over-simplified version of OOP; C++ is much more powerful (albeit harder to use!)
Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV?
You expect a 1995-grade compiler back in 1985? Fine, while you're at it, can you complain about LPs, I'd like those to be standard again too... The point is, when C++ was born, that BNF was too hard to write outside of academia, and it took those extra ten years before computers and compilers that could handle it were available.
Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?
Your definition of "basic functionality", not mine. I'm quite happy writing code without cramping my style around garbage collectors. I'm not demanding you stop using GC, so I'd appreciate it if you stop demanding that I must use GC. I find GC moronic, I can manage memory perfectly well on my own thank you (I learned it very well while becoming a kernel programmer).
"cin >> s, shift right or method call?" Method call. ...(e.g. if 'cin' in your example isn't a stream.)
Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise.
He's exactly right. "cin" always means "character input stream", just like Java's "clone" always means "deep copy of an object" or C's "errno" always means "error number".
Bjarne says that "a * b" for matrix multiply and "a b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.
Me, I blame the fool who thought a string should be a 1xN matrix and got slap-happy with automatic type conversions. Operator overloading is a way for a programmer to make semantic conventions that are blindingly obvious be reflected that way in the code; they are not a tool to hide programmer laziness. And unnecessary typecasts are a sign of poor design and laziness (a programmer problem), and not a problem with the underlying language.
C++ ain't a perfect language. But I like the power of C++. If you don't appreciate that power, fine ... but realize there are a lot of people out there who do, and your uninformed criticism doesn't dampen my love of C++ in the slightest.
Which ripped off Gilgamesh (Sumerian) and Sinue (Egyptian), which I'm sure ripped off far older stories that are lost to prehistory.
And frankly, what is the benefit of altering the core source? I can't think any, and I'd love to hear a legitimate reason. Well, I can think of one ... to wipe out the work of the original authors, which seems to be what the GPL zealots want but that, ironically, goes completely against the principles of the GPL!
Dynamic translation: 25x slowdown.
Dynamic translation with aggressive caching: 2-5x slowdown.
Google for Qemu - it's an open-source program that does sparc to x86 dynamic translation, with a 5-10x slowdown.
Dynamic translation does not decode the opcode on each instruction - it would be very expensive, and in fact more expensive than your description suggests. Dynamic translation instead recompiles one instruction set into another instruction set, much like a Java VM translates java bytecode into machine executable. (In fact, exactly like ... they use the same JIT optimizations).
But I digress... the reason to not emulate UltraSPARC is because of the hardware. Sparcs have fantastic caches and good bus performance compared to x86 CPUs, they have much better performance monitoring (e.g. counting TLB misses and the like), and a superior ISA that makes many performance-critical tasks (like context switching) cheaper. Opterons (and, notably, NOT Intel's 64 bit offerings) go a long way towards catching up on the raw performance metric, but they still aren't up to par - mostly because they don't scale beyond about 8 processors well, and Opterons use raw MHz to make up for other processor deficiencies.
And yes, technically, the grandparent is incorrect, zones do not provide kernel isolation. Recall the debates about the difference between a kernel (e.g. Linux) and an operating system (e.g. GNU/Linux)? Same here - Solaris Zones virtualizes the operating system (e.g. the GNU-equivalent pieces) without virtualizing the kernel (e.g. Linux). UML virtualizes everything (GNU/Linux). Zones has a lower overhead than UML, and allows better utilization of system resources.
UML is (comparatively) easy. Zones is hard, because you have to have a very robust kernel to make it work. Linux will never have Zones because the core Linux hackers (Torvalds included) would never tolerate the scale of changes needed to put the support Zones needs into a kernel. Thus, Linux will have to subsist on high-overhead programs like UML. Linux is by hobbyists, for hobbyists ... and it shows.
Swap and temp are the most active parts of your disk! The last thing you want is to hammer the same bytes of memory with write after write after write. Regular data on a flash drive, great; swap, stupid.
Here's one of the things I learned in high school: how to understand a person's motivations through his writing. Allow me to take a swing at yours? You write describing "kids" as second-class citizens to be ignored until sufficiently mature to become ... you. Sorry, friend, but I don't want to be you.
My opinion is that the tracking process is the check on the whole system. It takes effort to follow someone - yeah, four cops can probably reconstruct where you are every hour of every day, but the cops have better things to do than watch Joe Citizen. If Joe Citizen really were a concern, the cops should get a warrent - THEN this GPS makes sense.
The information about where you are is public - you can't hide it. But hiding a GPS on you is tantamount to self-incrimination - the GPS is broadcasting your location. There is a world of difference between spending a cop's time and effort following a person, and dropping a bug once and receiving a complete report about where a person goes. The information is the same; the effort required is vastly different. And a GPS transmitter crosses the line between passive surveillance and active interrogation.
our constitution says nothing about a right to privacy, the only privacy is that which is granted by individual laws
Read Amendments 9 and 10, if you want an explicit right to privacy. Those amendments were added specifically to prevent some joker from making up new government powers - which this police department tried. The Supreme Court specifically recognizes an "expectation of privacy" (I believe the case involved intrusive and obscene mail, and the right to not have to see it). The justification is Amendment 9 (or 10, I forget which) and the general trend of privacy preservation in the first ten amendments (assembly, search and seizure, quartering soldiers, etc.). So yes, Americans do enjoy a right to privacy. The right is not nearly so strong as, for example, the right to free speech, but privacy is a recognized right. And it's in constitutional law, which trumps any act of Congress or any other government.
No, because the parking ticket is a legal document issued via "due process". You can of course contest this process (by going to court to fight the fine), but most parking tickets truly are violations.
Translation: Let an ADD-superman do all the interesting work at your company, and make the rest of the peons do the drudge work.
Thinking you can do 10 times the work of someone else? That's not intelligence ... that's arrogance. General culture doesn't hate ADD or goth/punk subculture - hate is for the superiority complex that so many denizens of that subculture adopt.
Defense in depth. Malicious code should never be able to compromise your system in the first place, and we shouldn't bend over backwards preventing malicious code when it's perfectly acceptable to run malicious code (hint: Java's sandbox does it right). It is far, far easier to prevent malicious actions than to prevent all malicious code.
Doesn't matter. Fact is, if even 0.1% of the downloaders check, any compromised original will be detected in just a matter of minutes - hours at the worst. Mother at home will grab it... then the media the next day will loudly announce the problem, the antivirus companies will tear the binary apart and release updated signatures in a few days, and her virus scanner will tell her about the problem in about a week. This does assume she runs a virus scanner... but if she doesn't, she's probably compromised already.
What the Slashdot crowd seems to be missing is that we don't need everyone to follow the MD5 signature. We just need an informed and vocal minority - e.g. Slashdotters - to detect the problem and pick up the pieces afterwards.
And the Evil Turkish Empire is about to learn what happens when he crosses both Russia and Austria every turn for two game years... we finally got him flanked!
Sun's not afriad of that ... Sun's afraid of the other direction not working. For example... say Solaris has whiz-bang feature A. Some eager developer ports A to Linux. Some better developer makes A v1.1, with some bug fixes and interesting new features. Everyone decides A v1.1 is really cool... except Sun, which can't bring the code back into Solaris because it's GPL and OpenSolaris isn't.
Basically, it's a license that permits redistribution, but always permits Sun to fold back code changes into a proprietary Solaris product. Kinda like StarOffice & OpenOffice...
Yeah, I can write a patch to the linux kernel (or any other GPL project) and license it however I want. But for anyone to make use of my patch, they'll have to make use of GPLed code as well - what, you expect me to believe that my patch will cleanly apply to the BSD kernel?
If an author contributes code to a large GPL codebase, he is de facto required to GPL it. Sure he can release it under some other license; however, to make use of it, everyone else will have to apply it to the original GPLed code, which immediately brings it back under the GPL. The author has your so-called freedom in name only, but can never make use of that freedom; in my book, that means the author is just as restricted as the GPL.
The GPL limits the licenses YOU can put on OTHER PEOPLE'S WORK
Let me point out again: an author's work is worthless without the GPL code that the work modifies. Thus, the author must de facto release his code under the GPL - thus, the GPL is viral. I am reminded of a Henry Ford quote: "You can choose any color. As long as it's black."
The GPL is a great license ... for anyone who believes all code should be GPL. For everyone else, it's just as bad as a Microsoft EULA.
Before you respond, answer this question: What benefit would Sun get from releasing OpenSolaris under the GPL instead of this MPL-clone? Not what advantage YOU get ... I'm asking what advantage Sun gets.
I'm not claiming the GPL is evil. (Nor, in fact, am I claiming Microsoft's EULA's are evil). I am claiming that the GPL is overused, that too many GPL advocates see "Open Source" and assume GPL the complain when it's not GPL, when Open Source actually encompasses a far broader range of licenses.
IANAL, but the only significant (to me, at least) difference I saw is Sun retains for themselves the authority to release the code under another license in the future.
My interpretation: they want to make sure that any code someone adds to OpenSolaris can still be distributed by Sun as closed Solaris. Too many GPL zealots would love to cripple Sun by adding GPLed code to OpenSolaris and thereby prevent Sun from distributing closed-source products, so I think this is a pretty reasonable addition. To any GPL zealot out there: most of us don't believe the GPL is manna from heaven, but rather view it like Microsoft: attempting to monopolize and homogenize the software market under one distribution scheme. I'm pleased to see Sun trying to find a way to release code without pandering to the GPL mob.
Now, for those not paying attention, let me repeat myself ONE MORE TIME.
It's the MPL
It's the MPL
It's the MPL
It's the MPL. Got that?
The careful Slashdotter who actually follows links will immediately discover my two opinions on the matter.
Since the chip thus can't be used in a shared-memory configuration, a cluster is ideal. (And frankly, a better use of resources than cramming SMP chips like modern x86 into single-processor boxes and clustering those like the latest Linux-cluster-of-the-month).
Honestly - the system is brilliant. With one catch: the paraniod side of me sees some purchasing department comparing one of these, and a similar Sun workstation, then buying this one because "it has more CPU power". Yes ... if you run an app that works over a cluster. If it's a shared memory app, the Sun/SGI/IBM/whoever workstation will leave this one in the dust.
I see one very immediate use for these machines: developing cluster applications! Apps that run on 500-way clusters really do need to be tested on smaller clusters before they consume expensive cluster time - this machine is PERFECT for such testing! Or at least, far better than anything else out there...
I thought I had a 386SX that had cache - not onboard, but soldered onto the motherboard. Or maybe I'm thinking of another machine. Alas, I don't have the system or the specs anymore, so I can't be sure.
re:FSB, I shouldn't have claimed pathological cases. The fact is, the x86 architecture is very well suited to scale up to multiple CPUs even in leiu of the FSB's limitations - and the grandparent seemed to imply otherwise. Now, a slow FSB has some interesting pathologies, but the general case performance, with good caching, is actually pretty good!
I'm actually quite impressed at how much performance system architects have gotten out of modern processors even given the slow FSBs - with appropriate caching, prefetching, and upcoming multi-core designs (I'm actually looking to the 8-core Niagra as a better example), the FSB's speed is becoming less and less of a bottleneck.