Correct, there cannot be any perfect system, except in the very limited case of exactly 0, 1, or 2 candidates/parties running. That's sort of the point of the Arrow Impossibility Theorem
No it isn't, unless you're being tautological and defining "perfect system" as "one that meets the Arrow Impossibility Theorem criteria". Just reading through the definition of Arrow, IIA didn't seem obviously necessary or correct for a fair/perfect system to me. I then looked at the Wikipedia article and it seems that in fact, altering IIA makes designing a fair voting system possible and that that is what many proposed systems do.
Essentially, it looks like the point of the Arrow Impossibility Theorem is that "this set of criteria is too simple to accurately model what real-world voting systems are trying to do". It does _not_ say that any sufficiently non-trivial system cannot be fair; it says they cannot meet an arbitrary set of criteria.
(The whole thing is busted, and strikes me as akin to Econ 101 arguments about people being non-rational; classes often start off talking about utility functions, then switch to dollars for simplification of math, then go on to point out that people aren't rational because they won't bet their $1,000,000 life savings on a 100-to-1 shot at $100,000,001--without recognizing all the lectures they've just gone through about how the marginal value of someone's first dollar is greater than the next and that utility is not actually equal to dollars. No, people don't always behave economically rationally. But them not agreeing with your bogus definitions isn't an example of that)
Wesnoth provides a good template for FOSS game development, with their ongoing threads on tile design, art direction, music development, sound effects, etc that are the game-art geek equivalents to the more usual programmer's development boards.
You get 20 page threads on redesigning the sand tile graphics or how to tweak a particular piece of music. That attention to detail for the art/design side of things on top of the graphics is really necessary for a modern game.
Ah, then you have a buffer overflow, which is something it's generally considered a good idea to fix anyway. You should thank your thread for pointing out the problem.
A process would crash anyway, it would just be obvious which one had the problem instead of possibly wasting your time figuring that out.
Certainly there are lots of things that can be written better with processes rather than threads. Web servers come to mind. But there are also lots of things where you really want threads... you can "share" memory between processes but it's almost always a much slower process than within a process.
It's not much slower. It's even a bit faster in a lot of cases, since you only have to worry about TLB synchronization for the parts of memory you're sharing I agree, though, that there are certainly times when you want threads.
IBM, Sun and SGI (well not so much SGI anyway) don't make money selling shared memory machines for a hundred times the price per processor that a similar sized cluster would cost because their customers like having everything in one box.
I'm not sure that I understand what you mean here, nor how shared memory architectures are really relevant to the sort of shared memory we're talking about...
As you might suspect, I learned to program in an age when you had to look out for your own memory as well as everyone else's and I haven't completely bought into the modern view that the OS/architecture/language should protect the sloppy programmer. Yeah, being able to poke about everyone's memory isn't such a hot idea. But you should be competent enough to generally avoid stepping on your own toes.
It's not that it should protect them. It should kill the sloppy code ASAP, do as good a job at pointing out where the problem is as possible, and protect the clean code from the sloppy code.
If a buffer overrun in a multithreaded program tries to write in another thread's memory, you get odd behavior or crashes in the other thread. The original thread continues running, behaving strangely until it tries to hit memory it doesn't have the rights to when it'll die. If you'd used multiple processes, it wouldn't be "coddling" the sloppy code--it'd be killed immediately when it tried to access outside code.
More to the point, though, you never know what is going to cause problems. Just looking around a modern desktop, the file browser, web browser, status bar, text editor, music player, and many other programs all use plugins written by 3rd parties. Almost everything uses shared libraries. Isolating the instability that a bug in any of that can cause is a good thing, and making it easier to find that bug is a good thing.
Threads don't require the loss of memory protection, they involve the loss of enforced memory protection. In other words, they give you the choice.
But not a very granular choice; many systems want to shared only a small part of their memory, but for some reason go with threads (thereby sharing everything.
Lots of things are a LOT easier using shared memory. Some things pretty much require it.
Yes, but thankfully shared memory works fine with processes. And it tends to lead to more stable solutions and be easier to program in the long run; threads often _seem_ easier because you don't have to think about what to share--you just share it all. But that often leads to unforeseen problems unless you're very careful to plan out what things are accessed from where--exactly the work that you needed to do things with multiple processes + shared memory, but the latter enforces your decisions about what to share more rigorously.
I'm not against threads in all cases, certainly. If the vast majority of your memory needs to be shared, particularly when there are very complex shared data structures, then they're the way to go. But too many programmers reach for threads whenever they need to do multiprocessing, when the initial preference really should go to processes unless you know _why_ you need threads.
As for the browser crashing when one tab goes down, that's simply poor programming. You can restart a crashed thread just as easily as you can restart a crashed process.
The problem is that the crashed thread could have overwritten arbitrary memory in other threads, possibly including code, and can cause other threads to crash a lot more easily than a crashed process can bring down other processes.
Memory protection provides isolation, and helps limit the damage that bugs can cause.
Threads are quite nice, and they cut down on the number of mysterious entries in your process list
There's no reason right now that modern OSes can't share program IDs in the process list for processes; in Linux, use CLONE_PID without CLONE_VM, for instance. That's such a cosmetic change, though, that it's hard to think other OSes won't catch up once programmers realize that they have good multiprocess solutions available now on Windows and OS X (as well as Unix clones), and that throwing out memory protection between different components of your program is just stupid.
And honestly, end users would probably be a lot happier to have a single tab of their browser not crash out the whole thing than they would to have a few less entries in the task manager (which the vast majority of "just plain endusers" barely use at all). It's a nice incremental step, but far less important to the user experience than keeping protected memory around and keeping apps much more stable. I'm not saying it's not important, but just from a UI standpoint it's a lot less important than the things that using multiple processes in lieu of threads bring to the table.
Even if you don't have Erlang-style coprocesses, you can still go with other common multiprocessing solutions. Programmers have been writing multiple process solutions in C since before threads existed in any mainstream OS, and the vast majority of the time they're a much better choice than threads--the only real difference between the two being that threads throw protected memory out the window to a pretty large degree. IMO, if Windows had had good support for multiprocess solutions long ago, threads would be more appropriately used in somewhat limited circumstances.
Nowadays, with CreateProcessEx/NTCreateProcess Windows _does_ have good copy-on-write process solutions, but it's going to take a long time for the culture to move away from a knee-jerk "threads are the way to go for multiprocessing!" opinion (indeed it's been years since XP brought those solutions mainstream and only recently are they being exposed in any major programming venues.
On every new machine I get, first thing I do is siwtch off the capslock key and redirecting it to left-shift, I assume many people do the same, so we have 3 Shifts.
What you map it to usually depends on your editor. Emacs users map it to ctrl, vi users map it to esc.
(I've never heard of mapping shift before, and given that it's right next to a shift key that doesn't seem like a big help to me but if it helps you then do it!)'
On modern systems, threads are themselves first-class constructs
Not in, say, Linux or Plan 9. Context of execution are first-class constructs, and both threads and processes are special cases of COEs.
A process has things like memory-tables for virtual memory, handles for objects, files, socket connections, etc. A process always contains at least one thread (this isn't always true while a process is being set up or torn down, but it's true when most anyone's code is running).
The latter sentence here is nonsensical on many modern systems.
The core distinction which applies to most common modern systems (Windows, OS X, Linux, modern Unices, etc) is that:
In a multithreaded program, the threads all share memory (aside from the stack and possibly thread-local storage). This can be alternately phrased as threads lack memory protection from each other. Processes do not share memory except what is specifically allocated as shared memory (through CreateMemoryMapping, mmap, shm_get, or whatever)
When you are making the choice of whether to use threads or processes, your fundamental question should be "Do I want to implicitly share all memory?", or "Do I want to throw out memory protection?". Sometimes the answer is yes, but more often it's no (in which case you probably want to go with multiple COW processes, which the Unix/Mac crowd is familiar with through fork() but the equivalent NTCreateProcess with a NULL SectionHandle is much underpublicized on Windows).
Additionally, some operating systems support fibers.
Fibers are pretty tangential to the conversation and can also be implemented in user space. They're not really threads (or processes) at all, they're just coroutines. Java's "green threads" are one common example.
Take for example a simple thumbnail-generating program (a form of is used by everyday users). If the program is written in its traditional linear model, it would not take advantage of multiple processors or cores (unless you ran multiple instances of it or otherwise manipulated it in an unplanned fashion). However, if the program utilizes threading, it could become scalable without requiring any intervention.
If it used multiple processes, it could become scalable without requiring any intervention.
If it used multiple processes, it also wouldn't be throwing out a good portion of all the effort the OS designers spent implementing protected memory, and it would by necessity be more explicit about exactly what resources it was sharing--meaning fewer of the common multi-processing bugs.
The ideal steps to take to encourage good parallel programming, IMO, would be: 1. Microsoft does a better job of publicizing the NTCreateProcess/CreateProcessEx call, in particular that a NULL SectionHandle results in a true copy-on-write process (like a fork()'d process in Unix/Linux); true COW processes are required for efficient multiple process programming. Too few Windows programmers know how to do that as the standard CreateProcess/spawn() type calls are dog slow and unusable for efficient solutions; consequently, a legion of developers believe that using multiple cores requires threads (and all the problems they bring). 2. Java exposes a better multi-process API. Basically because of (1) they went in the "threads for everything" direction at the outset, for portability; thankfully they've moved away from that, allowing select()-style calls and other state-machine friendly thigs in more recent years. Getting good multi-process support would be the last big step here.
It's a shame that the single-threaded model became so ingrained in everything, including linux. For an example that comes to mind, why do I need to wait for my mail program to download all headers from the IMAP server before I can compose a new message on initial startup?
I'm of the opposite opinion; it's a shame that so many people equate parallel processing with threads. When there's not much shared data, using multiple processes keeps memory protection between your parallel "things", decreasing coupling, increasing isolation, and generally resulting in a more stable system (and for certain things where you can avoid some cache coherency problems, a faster system). Your example is perfect; there's really no good reason to use a thread for such lookups. Another process would do, or even better just use select() and avoid all the pain (and bugs) of a multithreaded solution.
OS developers spent a lot of engineering time implementing protected memory. Threads throw out a huge portion of that; a good programmer won't do that without very good reasons. Some tasks, where there really are tons of complicated data structures to be shared, are good candidates for threading. More commonly, though, threads are used either because the programmer doesn't know any better or because they allow you to be a slacker about defining exactly what is shared and mediating access to it. The latter is especially dangerous; defining exactly what (and how) things are shared goes most of the way toward eliminating multiprocessing bugs, and threads make it easy to slack off on that and get a "mostly working" solution that occasionally deadlocks, fails to scale, etc.
Use processes or state machines when you can, and threads when you must.
Another issue is that once you have more than one processor, two threads really can run at the same time which can show up all kinds of bugs you would never notice on a single core system.
That's true as far as it goes, but it's worth remembering that it's not at all a "bug" to assume that things that execution happens in order in a single-threaded process. Moving to multi-threading doesn't expose bugs you didn't notice before. It opens up a whole new class of bugs and requires explicit management of serialization. In general, it is not a case of sloppy programming being hidden on single-processors; it's that programming threads is very different and much harder, and you can't just implicitly parallelize existing (bug-free) single-threaded code.
Note that I'm not disagreeing with you--when multithreaded code that's run on single cores can hides some of the serialization bugs, that really is wallpapering. But it's far from the common case as to why bugs show up in multithreaded programs, and it's worth pointing out that it's not just "programmer laziness" making those dual cores idle a lot. Multithreading is difficult, and it's often a better idea to avoid it and go for stability--it all depends on the value of speed for the particular application.
The main problem I can see is with testing for errors. With multiple threads it's up to the OS on how it juggles them around and that juggling may be different for every test run. So you could run the same test a hundred times, then suddenly, you could get a failure. So multi-threading throws in a certain random aspect into the software which never used to be there.
Precisely. Multithreading introduces a huge level of complexity, part of which is beyond the bounds of your program; that in turn makes writing tests much more difficult, and decreases your confidence that a test suite is really catching the bugs it's intended to test.
What does this have to do with cognitive dissonance?
I agree, I don't see the relation.
That typically comes from paying a high price for a low return (not just financially/materially either).
Not really.
Cognitive dissonance is tension from antagonistic thoughts. Canonical examples are things like watching the rascist frat boys in Borat and not knowing whether to laugh or cry, or seeing a beautiful woman's body with an ugly demon head on it.
Many psychologists consider it the root of most humor (hearkening back to the old "Tragedy is when I cut my finger; comedy is when you fall down a manhole cover and die").
It might come into purchasing if there's a difficult to analyze return (e.g. buying that donut you don't need, where it's high return for about 1 minute and then a much lower or even negative return) but that's different from just feeling ripped off by getting a low return on a high price.
The right to a jury trial is not universal. A jury is only needed if there are questions of fact to be decided - juries decide facts, judges decide the application of laws.
Judges can limit their instructions to the juries, and legal professionals often assert some variant of the above (probably as wishful thinking), but juries absolutely have the power to determine the application of laws to a large degree. Even if jurors come out and say explicitly that they believe the facts indicated that the law was violated, but that they didn't believe the law should apply in the specific case, their decision will not be overturned--there's mounds of precedence upholding jury nullification. Once they reach a verdict, it stands regardless of why they reached it, barring normal appeals or very unusual jury tampering circumstances.
The "juries decide facts, judges decide law" meme is a very dangerous one to our legal system. Heck, the whole purpose behind the right to jury trials in the Magna Carta was to stop one capricious individual from arbitrary judgement of one individual.
Side note: even the most extreme pro-judicial advocates will admit that juries have a role in deciding the penalty in addition to the facts.
just look at celebrex: it's just an NSAID. nothing that aspirin can't handle. but they modified the chemical slightly, patent that, the effects are slightly different, but the slight effects are relabelled massive and brilliant improvements in function, and you have a market
Celebrex (and Vioxx) are COX-2 specific inhibitors. Other NSAIDS (like aspirin) inhibit both COX-1 and COX-2. COX-1 is responsible for maintaining cellular homeostatsis and is generally not something you want to suppress; COX-2 is responsible for pain and inflammation.
While COX-2 inhibitors are no more effective at managing pain and inflammation than older NSAIDS, they have a much lower incidence of certain side effects, especially long-term gastrointestinal problems.
So, yeah, for occasional use they're basically equivalent. But if you have, say, Crohn's disease (where traditional NSAIDS are contraindicated), COX-2 inhibitors can be a significant improvement to your quality of life.
The breadth and depth of cryptographic skill,. experience and knowledge behind the wire at Cheltenham and Fort Meade is orders of magnitude than that outside. The review process internally is actually far higher quality than that externally. This isn't like software, where even Microsoft doesn't employ a measurable fraction of the software engineers in the world. GCHQ plus NSA is the vast majority of the cryptographers, plus they have libraries and testcases and methodologies dating back fifty years that the rest don't have access it.
That used to be absolutely true. Over the last 15 years, there's been a huge boom in private-sector cryptography.
This reminds us all of the S Box hoo-hah, where elaborate theories were put forward by open community `experts' about the `flaws' in the S Boxes in DES. It turned out, of course, that they were optimal against an attack that wasn't even public, and close to optimal against other attacks that (allegedly) weren't known to anyone.
Yeah, at the time the NSA was about 20 years ahead of the open community on things like differential cryptanalysis.
Since then, the lead has deteriorated significantly with the proliferation of public-sector mathematics. Even former NSA employees have been quoted as saying that they're still ahead, but not by very much.
Yup. I saw that in a contract, told my soon-to-be boss that there was no way in hell that I'd ever sign such a thing, he talked to his lawyer, and we got it stricken from the contract. That easy.
+1 on this. I've gotten the last 5 employment contracts I signed amended to eliminate one-sided language, and I've never had a potential employer refuse reasonable changes (even at _enormous_ companies where you'd think the response would be "that's corporate policy set by headquarters, we can't change it). A lot of the time it's just boilerplate that they copied over from some sample employment contract, not something they care about.
If you just ask, reasonable people tend to be reasonable--especially when you negotiate such changes before you've started working somewhere.
I've been using a Sandisk 32 GB SSD on a Dell Latitude D630 running Vista for about 3 months now. This wasn't cheap, and even with an early adopter mindset, this is a big disappointment; it does indeed reads much faster (about 30 times), but writes at least 3 times slower than the same D630 running a SATA. My typical usage involved web/email, Microsoft Office, photography/photoshop, compiling large projects, etc.
Quiet is great, more battery is fine
I found your review a little frustrating, like reading a sports car review that focused on the small trunk space.
Does the drive deliver on the quit and low power fronts? I'd gladly give up half the speed for a 20% better battery life and silence.
Also, SSDs are NOT expensive! A CF-to-IDE adapter costs $15, and a 2GB CF card costs about $30. Two gigabytes is more than enough to boot an OS and start a RAID. Don't waste your money on a 64GB CF card. The CF+RAID hybrid approach is the way to go.
If your only concern is less maintenance, that's a neat solution. More generally, the CF-to-IDE adaper with larger CF cards does seem interesting since the RAID loses what many people feel are the prime advantages of SSDs (mainly noise and heat, also power for portables).
I can understand a week, but honestly...if you're leaving your customers vulnerable for over a month, they might start looking elsewhere
Exploits should be a high concern for any company
Seriously. We normally have a turnaround of a few hours on security fixes; however long it takes to code, 45 minutes to run the automated battery of unit and integration tests, and a couple hours for the human testers to do their work.
For client feature requests, depending on the priority and the size of the request it's from hours to months.
FWIW ours is what I class as a mid-size project (just over a half million LOC).
Battle for Wesnoth is a turn-based strategy game; raise armies and fight battles. Play solo campaigns where you can advance your troops' skills, or play short battles against other players online. http://www.wesnoth.org/
There are all kinds of trophies for smaller achievements, so first-time players can hope to get something but it's still competitive for experienced players--I pulled off 6 ascensions in a row at the June tournament and didn't make the top 3 for most consecutive, so the level of play is quite high.
Ever file anything in small claims court against a large company? Not so easy. Just "serving notice" can be a challenge.
Corporate agents are a matter of public record, and in most places the sheriff will do the actual physical serving for a nominal fee (it's around $18 where I live). Of course, in a small claims case even a nominal fee may be a large percentage of the dispute.
Geez, with how horrible you make MS Word sound, it's a wonder anyone uses it at all! The productivity of those that do must be pretty awful as well... I mean, with 99% of people not able to do anything but plain text it seems like businesses are SOL, what with the proprietary lockin and all.
That's not all that far from true. Despite all the bickering about doc and odf going on here, most of what businesses send is plain text or HTML (including most emails), with PDF and jpg/gif as the next closest competitors.
One place I'm familiar with hosts about 25 business intranets for various businesses; going through the "shared documents" arena I find about 3000 text files, around 3500 PDFs, 900 jpgs, 6000 GIFs, and just over 100.doc files (a handful of CSV, ZIP, PS, TIFF, and BMP but no XLS, RTF, PNG, TAR/GZ/BZ2, or TeX files); all of those are dwarfed by the majority of internal communications (which are in the main intranet as HTML, or sent as text emails). There are a lot more business-application-specific files than.doc (what would be, say, autocad files if the businesses in question were engineering firms), about 1500 in the various business-specific formats.
IMO, the importance of word processor formats is wildly overstated. I haven't really seen Word (or any other word processor) used much since my school days for anything other than "type a letter, print a letter". That's an important role, but it's not one where it matters at all what file format you use on your own drive. What gets distributed is paper.
That's frickin' rude, man. Seriously, if I was doing business with you, especially where I was paying you, and you sent me some link to a new office suite because you sent me documents I couldn't read, I would cease to do business with your company.
Businesses tend to be more pragmatic than that. If someone sends us a.doc file that I can't open, we'll go find OpenOffice or the free Word viewer or something rather than ceasing to do business with them. If it's a regular business partner, we'll try to get them to send text as text rather than a huge.doc with no formatting and 1-2 paragraphs of text in it (which seems to be what almost all.doc files I receive are), and csv rather than xls. If it's a one-off, it's easier just to scrounge for a workaround.
OTOH, it's never worth the risk of sending an odd format when something standard will do. I don't think I've needed to send anything other than text, HTML, jpg/gif, or csv for years. If I did, I'd go with whatever seemed easiest on all sides (probably PDF).
On the main topic, I'd guess that most openoffice users do save in Microsoft format. The only reason I ever see anyone install it is to read and respond to those crappy.doc attachments people sling around, and I'd guess that's the most common reason for having it.
I find that the CTS is actually worse in my dominant arm. I believe it is at least in part due to mouse use, because I find that when it flares up, it's far more painful to use a mouse than it is for me to type.
FWIW, I found that switching the mouse to the left hand for a month and then alternating every couple of weeks made all my arm pain go away. It takes a day or two to get used to using the mouse in the off-hand, but was well worth it for me.
Anchorage, AK is not in the "continental US" even though it is on the same continent as 48 other states. The term is (nonsensically) a synonym for "lower 48" or "contiguous states."
I've always heard "contiguous 48" to include all the states (plus DC) other than Alaska and Hawaii, while "continental US" includes Alaska. But upon some googling, both definitions have traction. Wikipedia notes that both definitions are widely used, that your definition is more common while including Alaska is more correct.
FWIW to put it in context I googled a few airlines; of the 7 largest airlines in the country, United, US Airways, and American include Alaska in their definitions of the continental US. Delta and Northwest exclude Alaska. Continental and Southwest I didn't find anything for.
Because of the ambiguity in definitions (and the existence of the unambiguous "contiguous" usage), I'd personally avoid using the term "continental US" if I was trying to specify the contiguous US.
(Wikipedia also notes that technically "lower 48" would exclude Minnesota and include Hawaii but that in practice is well-understood; I wouldn't have a problem using that term since I'm confident whoever I'm talking to would know what's meant).
Slashdot Mirror
Correct, there cannot be any perfect system, except in the very limited case of exactly 0, 1, or 2 candidates/parties running. That's sort of the point of the Arrow Impossibility Theorem
No it isn't, unless you're being tautological and defining "perfect system" as "one that meets the Arrow Impossibility Theorem criteria". Just reading through the definition of Arrow, IIA didn't seem obviously necessary or correct for a fair/perfect system to me. I then looked at the Wikipedia article and it seems that in fact, altering IIA makes designing a fair voting system possible and that that is what many proposed systems do.
Essentially, it looks like the point of the Arrow Impossibility Theorem is that "this set of criteria is too simple to accurately model what real-world voting systems are trying to do". It does _not_ say that any sufficiently non-trivial system cannot be fair; it says they cannot meet an arbitrary set of criteria.
(The whole thing is busted, and strikes me as akin to Econ 101 arguments about people being non-rational; classes often start off talking about utility functions, then switch to dollars for simplification of math, then go on to point out that people aren't rational because they won't bet their $1,000,000 life savings on a 100-to-1 shot at $100,000,001--without recognizing all the lectures they've just gone through about how the marginal value of someone's first dollar is greater than the next and that utility is not actually equal to dollars. No, people don't always behave economically rationally. But them not agreeing with your bogus definitions isn't an example of that)
Wesnoth provides a good template for FOSS game development, with their ongoing threads on tile design, art direction, music development, sound effects, etc that are the game-art geek equivalents to the more usual programmer's development boards.
See, for instance, http://www.wesnoth.org/forum/viewtopic.php?t=17985 for a music thread or http://www.wesnoth.org/forum/viewforum.php?f=18&sid=63c7d2dfdabda6e0fb7b78b91e80bcc2 for the art forum.
You get 20 page threads on redesigning the sand tile graphics or how to tweak a particular piece of music. That attention to detail for the art/design side of things on top of the graphics is really necessary for a modern game.
Ah, then you have a buffer overflow, which is something it's generally considered a good idea to fix anyway. You should thank your thread for pointing out the problem.
A process would crash anyway, it would just be obvious which one had the problem instead of possibly wasting your time figuring that out.
Certainly there are lots of things that can be written better with processes rather than threads. Web servers come to mind. But there are also lots of things where you really want threads... you can "share" memory between processes but it's almost always a much slower process than within a process.
It's not much slower. It's even a bit faster in a lot of cases, since you only have to worry about TLB synchronization for the parts of memory you're sharing I agree, though, that there are certainly times when you want threads.
IBM, Sun and SGI (well not so much SGI anyway) don't make money selling shared memory machines for a hundred times the price per processor that a similar sized cluster would cost because their customers like having everything in one box.
I'm not sure that I understand what you mean here, nor how shared memory architectures are really relevant to the sort of shared memory we're talking about...
As you might suspect, I learned to program in an age when you had to look out for your own memory as well as everyone else's and I haven't completely bought into the modern view that the OS/architecture/language should protect the sloppy programmer. Yeah, being able to poke about everyone's memory isn't such a hot idea. But you should be competent enough to generally avoid stepping on your own toes.
It's not that it should protect them. It should kill the sloppy code ASAP, do as good a job at pointing out where the problem is as possible, and protect the clean code from the sloppy code.
If a buffer overrun in a multithreaded program tries to write in another thread's memory, you get odd behavior or crashes in the other thread. The original thread continues running, behaving strangely until it tries to hit memory it doesn't have the rights to when it'll die. If you'd used multiple processes, it wouldn't be "coddling" the sloppy code--it'd be killed immediately when it tried to access outside code.
More to the point, though, you never know what is going to cause problems. Just looking around a modern desktop, the file browser, web browser, status bar, text editor, music player, and many other programs all use plugins written by 3rd parties. Almost everything uses shared libraries. Isolating the instability that a bug in any of that can cause is a good thing, and making it easier to find that bug is a good thing.
Threads don't require the loss of memory protection, they involve the loss of enforced memory protection. In other words, they give you the choice.
But not a very granular choice; many systems want to shared only a small part of their memory, but for some reason go with threads (thereby sharing everything.
Lots of things are a LOT easier using shared memory. Some things pretty much require it.
Yes, but thankfully shared memory works fine with processes. And it tends to lead to more stable solutions and be easier to program in the long run; threads often _seem_ easier because you don't have to think about what to share--you just share it all. But that often leads to unforeseen problems unless you're very careful to plan out what things are accessed from where--exactly the work that you needed to do things with multiple processes + shared memory, but the latter enforces your decisions about what to share more rigorously.
I'm not against threads in all cases, certainly. If the vast majority of your memory needs to be shared, particularly when there are very complex shared data structures, then they're the way to go. But too many programmers reach for threads whenever they need to do multiprocessing, when the initial preference really should go to processes unless you know _why_ you need threads.
As for the browser crashing when one tab goes down, that's simply poor programming. You can restart a crashed thread just as easily as you can restart a crashed process.
The problem is that the crashed thread could have overwritten arbitrary memory in other threads, possibly including code, and can cause other threads to crash a lot more easily than a crashed process can bring down other processes.
Memory protection provides isolation, and helps limit the damage that bugs can cause.
Threads are quite nice, and they cut down on the number of mysterious entries in your process list
There's no reason right now that modern OSes can't share program IDs in the process list for processes; in Linux, use CLONE_PID without CLONE_VM, for instance. That's such a cosmetic change, though, that it's hard to think other OSes won't catch up once programmers realize that they have good multiprocess solutions available now on Windows and OS X (as well as Unix clones), and that throwing out memory protection between different components of your program is just stupid.
And honestly, end users would probably be a lot happier to have a single tab of their browser not crash out the whole thing than they would to have a few less entries in the task manager (which the vast majority of "just plain endusers" barely use at all). It's a nice incremental step, but far less important to the user experience than keeping protected memory around and keeping apps much more stable. I'm not saying it's not important, but just from a UI standpoint it's a lot less important than the things that using multiple processes in lieu of threads bring to the table.
Even if you don't have Erlang-style coprocesses, you can still go with other common multiprocessing solutions. Programmers have been writing multiple process solutions in C since before threads existed in any mainstream OS, and the vast majority of the time they're a much better choice than threads--the only real difference between the two being that threads throw protected memory out the window to a pretty large degree. IMO, if Windows had had good support for multiprocess solutions long ago, threads would be more appropriately used in somewhat limited circumstances.
Nowadays, with CreateProcessEx/NTCreateProcess Windows _does_ have good copy-on-write process solutions, but it's going to take a long time for the culture to move away from a knee-jerk "threads are the way to go for multiprocessing!" opinion (indeed it's been years since XP brought those solutions mainstream and only recently are they being exposed in any major programming venues.
On every new machine I get, first thing I do is siwtch off the capslock key and redirecting it to left-shift, I assume many people do the same, so we have 3 Shifts.
What you map it to usually depends on your editor. Emacs users map it to ctrl, vi users map it to esc.
(I've never heard of mapping shift before, and given that it's right next to a shift key that doesn't seem like a big help to me but if it helps you then do it!)'
On modern systems, threads are themselves first-class constructs
Not in, say, Linux or Plan 9. Context of execution are first-class constructs, and both threads and processes are special cases of COEs.
A process has things like memory-tables for virtual memory, handles for objects, files, socket connections, etc. A process always contains at least one thread (this isn't always true while a process is being set up or torn down, but it's true when most anyone's code is running).
The latter sentence here is nonsensical on many modern systems.
The core distinction which applies to most common modern systems (Windows, OS X, Linux, modern Unices, etc) is that:
In a multithreaded program, the threads all share memory (aside from the stack and possibly thread-local storage). This can be alternately phrased as threads lack memory protection from each other. Processes do not share memory except what is specifically allocated as shared memory (through CreateMemoryMapping, mmap, shm_get, or whatever)
When you are making the choice of whether to use threads or processes, your fundamental question should be "Do I want to implicitly share all memory?", or "Do I want to throw out memory protection?". Sometimes the answer is yes, but more often it's no (in which case you probably want to go with multiple COW processes, which the Unix/Mac crowd is familiar with through fork() but the equivalent NTCreateProcess with a NULL SectionHandle is much underpublicized on Windows).
Additionally, some operating systems support fibers.
Fibers are pretty tangential to the conversation and can also be implemented in user space. They're not really threads (or processes) at all, they're just coroutines. Java's "green threads" are one common example.
Take for example a simple thumbnail-generating program (a form of is used by everyday users). If the program is written in its traditional linear model, it would not take advantage of multiple processors or cores (unless you ran multiple instances of it or otherwise manipulated it in an unplanned fashion). However, if the program utilizes threading, it could become scalable without requiring any intervention.
If it used multiple processes, it could become scalable without requiring any intervention.
If it used multiple processes, it also wouldn't be throwing out a good portion of all the effort the OS designers spent implementing protected memory, and it would by necessity be more explicit about exactly what resources it was sharing--meaning fewer of the common multi-processing bugs.
The ideal steps to take to encourage good parallel programming, IMO, would be:
1. Microsoft does a better job of publicizing the NTCreateProcess/CreateProcessEx call, in particular that a NULL SectionHandle results in a true copy-on-write process (like a fork()'d process in Unix/Linux); true COW processes are required for efficient multiple process programming. Too few Windows programmers know how to do that as the standard CreateProcess/spawn() type calls are dog slow and unusable for efficient solutions; consequently, a legion of developers believe that using multiple cores requires threads (and all the problems they bring).
2. Java exposes a better multi-process API. Basically because of (1) they went in the "threads for everything" direction at the outset, for portability; thankfully they've moved away from that, allowing select()-style calls and other state-machine friendly thigs in more recent years. Getting good multi-process support would be the last big step here.
It's a shame that the single-threaded model became so ingrained in everything, including linux. For an example that comes to mind, why do I need to wait for my mail program to download all headers from the IMAP server before I can compose a new message on initial startup?
I'm of the opposite opinion; it's a shame that so many people equate parallel processing with threads. When there's not much shared data, using multiple processes keeps memory protection between your parallel "things", decreasing coupling, increasing isolation, and generally resulting in a more stable system (and for certain things where you can avoid some cache coherency problems, a faster system). Your example is perfect; there's really no good reason to use a thread for such lookups. Another process would do, or even better just use select() and avoid all the pain (and bugs) of a multithreaded solution.
OS developers spent a lot of engineering time implementing protected memory. Threads throw out a huge portion of that; a good programmer won't do that without very good reasons. Some tasks, where there really are tons of complicated data structures to be shared, are good candidates for threading. More commonly, though, threads are used either because the programmer doesn't know any better or because they allow you to be a slacker about defining exactly what is shared and mediating access to it. The latter is especially dangerous; defining exactly what (and how) things are shared goes most of the way toward eliminating multiprocessing bugs, and threads make it easy to slack off on that and get a "mostly working" solution that occasionally deadlocks, fails to scale, etc.
Use processes or state machines when you can, and threads when you must.
Another issue is that once you have more than one processor, two threads really can run at the same time which can show up all kinds of bugs you would never notice on a single core system.
That's true as far as it goes, but it's worth remembering that it's not at all a "bug" to assume that things that execution happens in order in a single-threaded process. Moving to multi-threading doesn't expose bugs you didn't notice before. It opens up a whole new class of bugs and requires explicit management of serialization. In general, it is not a case of sloppy programming being hidden on single-processors; it's that programming threads is very different and much harder, and you can't just implicitly parallelize existing (bug-free) single-threaded code.
Note that I'm not disagreeing with you--when multithreaded code that's run on single cores can hides some of the serialization bugs, that really is wallpapering. But it's far from the common case as to why bugs show up in multithreaded programs, and it's worth pointing out that it's not just "programmer laziness" making those dual cores idle a lot. Multithreading is difficult, and it's often a better idea to avoid it and go for stability--it all depends on the value of speed for the particular application.
The main problem I can see is with testing for errors. With multiple threads it's up to the OS on how it juggles them around and that juggling may be different for every test run. So you could run the same test a hundred times, then suddenly, you could get a failure. So multi-threading throws in a certain random aspect into the software which never used to be there.
Precisely. Multithreading introduces a huge level of complexity, part of which is beyond the bounds of your program; that in turn makes writing tests much more difficult, and decreases your confidence that a test suite is really catching the bugs it's intended to test.
What does this have to do with cognitive dissonance?
I agree, I don't see the relation.
That typically comes from paying a high price for a low return (not just financially/materially either).
Not really.
Cognitive dissonance is tension from antagonistic thoughts. Canonical examples are things like watching the rascist frat boys in Borat and not knowing whether to laugh or cry, or seeing a beautiful woman's body with an ugly demon head on it.
Many psychologists consider it the root of most humor (hearkening back to the old "Tragedy is when I cut my finger; comedy is when you fall down a manhole cover and die").
It might come into purchasing if there's a difficult to analyze return (e.g. buying that donut you don't need, where it's high return for about 1 minute and then a much lower or even negative return) but that's different from just feeling ripped off by getting a low return on a high price.
The right to a jury trial is not universal. A jury is only needed if there are questions of fact to be decided - juries decide facts, judges decide the application of laws.
Judges can limit their instructions to the juries, and legal professionals often assert some variant of the above (probably as wishful thinking), but juries absolutely have the power to determine the application of laws to a large degree. Even if jurors come out and say explicitly that they believe the facts indicated that the law was violated, but that they didn't believe the law should apply in the specific case, their decision will not be overturned--there's mounds of precedence upholding jury nullification. Once they reach a verdict, it stands regardless of why they reached it, barring normal appeals or very unusual jury tampering circumstances.
The "juries decide facts, judges decide law" meme is a very dangerous one to our legal system. Heck, the whole purpose behind the right to jury trials in the Magna Carta was to stop one capricious individual from arbitrary judgement of one individual.
Side note: even the most extreme pro-judicial advocates will admit that juries have a role in deciding the penalty in addition to the facts.
just look at celebrex: it's just an NSAID. nothing that aspirin can't handle. but they modified the chemical slightly, patent that, the effects are slightly different, but the slight effects are relabelled massive and brilliant improvements in function, and you have a market
Celebrex (and Vioxx) are COX-2 specific inhibitors. Other NSAIDS (like aspirin) inhibit both COX-1 and COX-2. COX-1 is responsible for maintaining cellular homeostatsis and is generally not something you want to suppress; COX-2 is responsible for pain and inflammation.
While COX-2 inhibitors are no more effective at managing pain and inflammation than older NSAIDS, they have a much lower incidence of certain side effects, especially long-term gastrointestinal problems.
So, yeah, for occasional use they're basically equivalent. But if you have, say, Crohn's disease (where traditional NSAIDS are contraindicated), COX-2 inhibitors can be a significant improvement to your quality of life.
The breadth and depth of cryptographic skill,. experience and knowledge behind the wire at Cheltenham and Fort Meade is orders of magnitude than that outside. The review process internally is actually far higher quality than that externally. This isn't like software, where even Microsoft doesn't employ a measurable fraction of the software engineers in the world. GCHQ plus NSA is the vast majority of the cryptographers, plus they have libraries and testcases and methodologies dating back fifty years that the rest don't have access it.
That used to be absolutely true. Over the last 15 years, there's been a huge boom in private-sector cryptography.
This reminds us all of the S Box hoo-hah, where elaborate theories were put forward by open community `experts' about the `flaws' in the S Boxes in DES. It turned out, of course, that they were optimal against an attack that wasn't even public, and close to optimal against other attacks that (allegedly) weren't known to anyone.
Yeah, at the time the NSA was about 20 years ahead of the open community on things like differential cryptanalysis.
Since then, the lead has deteriorated significantly with the proliferation of public-sector mathematics. Even former NSA employees have been quoted as saying that they're still ahead, but not by very much.
Yup. I saw that in a contract, told my soon-to-be boss that there was no way in hell that I'd ever sign such a thing, he talked to his lawyer, and we got it stricken from the contract. That easy.
+1 on this. I've gotten the last 5 employment contracts I signed amended to eliminate one-sided language, and I've never had a potential employer refuse reasonable changes (even at _enormous_ companies where you'd think the response would be "that's corporate policy set by headquarters, we can't change it). A lot of the time it's just boilerplate that they copied over from some sample employment contract, not something they care about.
If you just ask, reasonable people tend to be reasonable--especially when you negotiate such changes before you've started working somewhere.
I've been using a Sandisk 32 GB SSD on a Dell Latitude D630 running Vista for about 3 months now. This wasn't cheap, and even with an early adopter mindset, this is a big disappointment; it does indeed reads much faster (about 30 times), but writes at least 3 times slower than the same D630 running a SATA. My typical usage involved web/email, Microsoft Office, photography/photoshop, compiling large projects, etc.
Quiet is great, more battery is fine
I found your review a little frustrating, like reading a sports car review that focused on the small trunk space.
Does the drive deliver on the quit and low power fronts? I'd gladly give up half the speed for a 20% better battery life and silence.
Also, SSDs are NOT expensive! A CF-to-IDE adapter costs $15, and a 2GB CF card costs about $30. Two gigabytes is more than enough to boot an OS and start a RAID. Don't waste your money on a 64GB CF card. The CF+RAID hybrid approach is the way to go.
If your only concern is less maintenance, that's a neat solution. More generally, the CF-to-IDE adaper with larger CF cards does seem interesting since the RAID loses what many people feel are the prime advantages of SSDs (mainly noise and heat, also power for portables).
I can understand a week, but honestly...if you're leaving your customers vulnerable for over a month, they might start looking elsewhere
Exploits should be a high concern for any company
Seriously. We normally have a turnaround of a few hours on security fixes; however long it takes to code, 45 minutes to run the automated battery of unit and integration tests, and a couple hours for the human testers to do their work.
For client feature requests, depending on the priority and the size of the request it's from hours to months.
FWIW ours is what I class as a mid-size project (just over a half million LOC).
Battle for Wesnoth is a turn-based strategy game; raise armies and fight battles. Play solo campaigns where you can advance your troops' skills, or play short battles against other players online. http://www.wesnoth.org/
Freeciv is a Civilization clone, also single player or multiplayer online. http://freeciv.wikia.com/wiki/Main_Page
And if you're willing to go really old-school, nethack is always available; the annual tournament is ongoing in the month of November. Current standings at http://nethack.devnull.net/tournament/scoreboard.shtml or enter for free at http://nethack.devnull.net/tournament/howitworks.shtml ; you can always telnet to nethack.alt.org to play or download from http://www.nethack.org/
There are all kinds of trophies for smaller achievements, so first-time players can hope to get something but it's still competitive for experienced players--I pulled off 6 ascensions in a row at the June tournament and didn't make the top 3 for most consecutive, so the level of play is quite high.
Corporate agents are a matter of public record, and in most places the sheriff will do the actual physical serving for a nominal fee (it's around $18 where I live). Of course, in a small claims case even a nominal fee may be a large percentage of the dispute.
Geez, with how horrible you make MS Word sound, it's a wonder anyone uses it at all! The productivity of those that do must be pretty awful as well... I mean, with 99% of people not able to do anything but plain text it seems like businesses are SOL, what with the proprietary lockin and all.
.doc files (a handful of CSV, ZIP, PS, TIFF, and BMP but no XLS, RTF, PNG, TAR/GZ/BZ2, or TeX files); all of those are dwarfed by the majority of internal communications (which are in the main intranet as HTML, or sent as text emails). There are a lot more business-application-specific files than .doc (what would be, say, autocad files if the businesses in question were engineering firms), about 1500 in the various business-specific formats.
That's not all that far from true. Despite all the bickering about doc and odf going on here, most of what businesses send is plain text or HTML (including most emails), with PDF and jpg/gif as the next closest competitors.
One place I'm familiar with hosts about 25 business intranets for various businesses; going through the "shared documents" arena I find about 3000 text files, around 3500 PDFs, 900 jpgs, 6000 GIFs, and just over 100
IMO, the importance of word processor formats is wildly overstated. I haven't really seen Word (or any other word processor) used much since my school days for anything other than "type a letter, print a letter". That's an important role, but it's not one where it matters at all what file format you use on your own drive. What gets distributed is paper.
That's frickin' rude, man. Seriously, if I was doing business with you, especially where I was paying you, and you sent me some link to a new office suite because you sent me documents I couldn't read, I would cease to do business with your company.
.doc file that I can't open, we'll go find OpenOffice or the free Word viewer or something rather than ceasing to do business with them. If it's a regular business partner, we'll try to get them to send text as text rather than a huge .doc with no formatting and 1-2 paragraphs of text in it (which seems to be what almost all .doc files I receive are), and csv rather than xls. If it's a one-off, it's easier just to scrounge for a workaround.
.doc attachments people sling around, and I'd guess that's the most common reason for having it.
Businesses tend to be more pragmatic than that. If someone sends us a
OTOH, it's never worth the risk of sending an odd format when something standard will do. I don't think I've needed to send anything other than text, HTML, jpg/gif, or csv for years. If I did, I'd go with whatever seemed easiest on all sides (probably PDF).
On the main topic, I'd guess that most openoffice users do save in Microsoft format. The only reason I ever see anyone install it is to read and respond to those crappy
I find that the CTS is actually worse in my dominant arm. I believe it is at least in part due to mouse use, because I find that when it flares up, it's far more painful to use a mouse than it is for me to type.
FWIW, I found that switching the mouse to the left hand for a month and then alternating every couple of weeks made all my arm pain go away. It takes a day or two to get used to using the mouse in the off-hand, but was well worth it for me.
Anchorage, AK is not in the "continental US" even though it is on the same continent as 48 other states. The term is (nonsensically) a synonym for "lower 48" or "contiguous states."
I've always heard "contiguous 48" to include all the states (plus DC) other than Alaska and Hawaii, while "continental US" includes Alaska. But upon some googling, both definitions have traction. Wikipedia notes that both definitions are widely used, that your definition is more common while including Alaska is more correct.
FWIW to put it in context I googled a few airlines; of the 7 largest airlines in the country, United, US Airways, and American include Alaska in their definitions of the continental US. Delta and Northwest exclude Alaska. Continental and Southwest I didn't find anything for.
Because of the ambiguity in definitions (and the existence of the unambiguous "contiguous" usage), I'd personally avoid using the term "continental US" if I was trying to specify the contiguous US.
(Wikipedia also notes that technically "lower 48" would exclude Minnesota and include Hawaii but that in practice is well-understood; I wouldn't have a problem using that term since I'm confident whoever I'm talking to would know what's meant).