Imagine a future where most U.S. tech-companies outsource R&D and production to India and china...oh...never mind
Having a great university system is the main force slowing outsourcing. Many of the most talented foreigners come to the US for education, and most who can stay, stay. Imagine how outsourcing would be galloping along if all the foreign workers and foreign professors in the US had stayed home and built up the tech industries in their home countries instead of coming here.
You know, somebody who read the rest of the thread and didn't read the article summary would think you were posting off-topic, because nobody else is talking about user experience. I guess it never occurred to anyone else.
Commercial web sites must put customer experience near the bottom when it comes to mapping, because I mostly see second-rate map links on company web sites. Even image-sensitive brick-and-mortar business like restaurants usually provide crude and unusable maps. Every prospective customer needs to know how to get to a restaurant. Restaurants depend on trendiness and/or friendliness, usually both. Google works; it's available; supposedly there are other decent options, too. What's the hold up? How long will it take before I can go to the web site of a nice restaurant in my city and have even odds of getting a usable map?
His point, which is correct, is that Microsoft has a business model based around supporting you. They sell you things. They must then deliver.
This is true but not worth much. Software purchases usually go wrong because of mistakes made by the customer, not the vendor. The vendor delivers the software as promised, and it turns out to be subtly incompatible with your needs, or integration turns out to be insanely expensive. Then how do you get your money back? You'll certainly never get back the money you invested in services and integration. You're stuck with a solution that's much more costly or less functional than envisioned and possibly even worse than you had before.
Then the money you paid comes back to haunt you, because irrationality (not to mention very rational political considerations by management) creates a very powerful bias in favor of persisting on the failed path. Even if your company doesn't renew the software licenses year after year (which is common enough with failed software purchases,) you'll still be pressured to use the system for a while so it looks like the money wasn't wasted. Even if the solution is shelfware, the mere fact that money changed hands can mean that you are forbidden to pursue alternatives. (At least officially -- inevitably, Perl scripts or Office macros proliferate like weeds on an abandoned construction site, until your company is dependent on a whole bunch of software most of which you don't even know exists.)
When no money has changed hands (merely hours and hours of expensive labor,) it's politically feasible to fall back on an old solution and spin the failed project as an experiment. It's acceptable to simply stop running a server that nobody uses, because turning it off is not seen as a symbolic declaration of some executive's failure.
Granted, it's not as cut-and-dried as all that. If the cost of your investment in a new OSS solution is well understood, then you might have the same problem throwing it away as you would with a purchased system. Your odds are much better when nothing is purchased, though, even if only for psychological reasons. And, of course, you also have the option to make modifications to the software and support it yourself. (Sometimes a trivial change is all it takes, but is Microsoft going to make a trivial change for you and risk a regression?)
All in all, the only thing a software purchase buys you is a commitment to make the product work as advertised, which is rarely a problem with commercial or OSS software from a reputable source. It doesn't cover analysis mistakes on your part, no matter how much the vendor encouraged you to make them.
Yep, I'm looking at my coworkers and seeing more people with active fantasy lives than with the guts to kiss a coworkers. Freakin' liars. I'm asleep every day from 1:00 to 2:00. Most days my eyes are open and I'm typing during that time. That's my "make mistakes so I can learn from them" time. I'm also a stone-cold ladykiller, but I've never kissed a coworker. Had a chance to, once, but she was drunk and I was chivalrous. The chivalry was wasted, but it wasn't a costly mistake.
Java did not go far from the plain old mutex, lock, and condition variable paradigm. Java's version is almost as flexible and a lot easier for beginners to understand, and Java steers beginners away from incorrectness (towards slowness, but that's the right direction for beginners.) It's still not so different from "raw" threading using POSIX, just more elegantly expressed. Outside Java, everyone is still doing "raw" threading in all of the popular languages, while various less-popular languages such as Erlang and Scala(*) experiment with radically different approaches. When the hammer starts to come down and more and more J. Random Codemonkeys have to take advantage of multicore processors or lose their jobs, there will be a big migration to one or more languages that make threading as easy as possible. I think that's what he's talking about when he says Python should be "the multi-processing language."
(*) People are stubborn in their prejudices and have already categorized Erlang and Scala as being "too hard" or "weird" or "languages for smart people." Even if Erlang, Scala, or another language has already nailed the next generation of threading concepts, people will wait for them to appear in a language with comfortable, low-brow marketing that assures them they won't fail to make the leap. The only thing Python has going against it is that many very smart people like Python -- HPC scientists use it to wrangle Fortran libraries, ESR famously praised it, it's popular in Google for scripting, and IIRC even Peter Norvig has said some kind words about it. Hopefully that doesn't doom it, because most of those people praise it for being less intellectually taxing than its similarly-powerful competitors.
You are seriously going to argue that introducing a race condition between name and info is a good thing?
I'm making a distinction between piecework hacks and systematic exploitation of these ideas. You're thinking on a much smaller scale than your first earlier implied (since you first referred the ideas in their most general form), and I think if I understand you now I don't necessarily disagree. Also, with respect to this particular example you're talking about correctness vs. cruft, which is an entirely separate argument.
Sure, why would you create a DSL for every thing when you could use a GL one instead? The interface is already there, just have it use system calls like a process. That's not rocket science
That is rocket science, in the sense that some kind of security model would have to be enforced to prevent malicious or careless users from borking the kernel. To avoid the overhead of constant checking, the security check would have to be done on the code itself when it is presented by the user, rather than on the code's runtime activity. The rocket science comparison here is particularly apt, since it's an old idea, has been demonstrated in practice, is routine for some uses (rockets take satellites into orbit; Java checks loaded bytecode to make sure it's safe for the VM), yet it is still only practical (so far) in a narrow range of applications. A DSL is much easier, because it can include a very limited set of abstractions and control flow facilities (or no flow control facilities at all.)
Concurrency is hard. Processes can't change that. The putative safety difference between threads and processes is mostly based on a comparison of very simple multiprocess designs with very complex multithreaded designs that use fine-grained locking. If you can use a "very good concurrency model" that's already implemented for your platform then you will be much better off in the long run, of course, no matter whether it's implemented on top of threads or processes. If you use a complex design based on intricate locking patterns, then you may never get it completely right. Ah, but it's rather impractical to do intricate fine-grained locking with processes, so nobody makes the mistake of tackling hopelessly complex locking problems when they're using processes.
In other words, the standard argument for processes over threads is pretty much the same as the (primary) one Linus uses for C over C++: If you use threads/C++ then you're going to do all kinds of stupid complicated things and doom yourself. If you use processes/C then you'll magically see all the simple designs that you overlooked when you were using threads/C++, because you have no choice. That isn't universally true; not everybody is frothing at the mouth to do all the nasty complicated things their tools allow.
do we really want languages to be chaining themselves to it?
It isn't crack. Making it available isn't the same as chaining people to it.
Ad-hoc optimizations of the sort you're describing are exactly what the kernel developers should be doing. Exploiting those techniques consistently and pervasively means linguistic and security model work. Think of the effort required to generalize the use of a DSL for the packet filter to all the configurable aspects of the kernel. (Or you could do it in a pervasive AND ad-hoc way -- maybe create a different DSL for every possible programmable part of the kernel -- but that would hardly be worth it.)
For another example, you can combine multiple system calls into one by defining lots of "combo" system calls. That's kind of an atrocity, but it might be worth it in a few especially critical places. Evidently Linux is getting along okay without it. Alternatively, you could hide the functionality in the platform somehow at the linguistic or linking level. That's what I'm talking about when I say a massive reworking would be required.
Or you can just blindly pretend that the kernel developers know everything, so if they haven't done it already it must not a good idea. I am starting to believe that the OSS kernel developers are really only good at copying after all.
They're "only good at copying" because they refuse to copy the "demonstrated benefits" achieved by researchers? I guess that would be insulting if it were coherent.
Demonstrating a performance improvement is only the first step in development. Researchers don't put their products through QA and deploy them to hundreds of thousands of users on dozens of platforms. Nor do they take on responsibility for maintaining their hacks through further changes and enhancements. Taking on that responsibility is not simply "copying."
The Linux kernel is open-source and is often used for kernel research. Anyone who makes improvements that are suitable for inclusion in the kernel are free to do so. If the kernel team doesn't accept them, then they're free to hire themselves out to Oracle or an embedded Linux company or any one of the hundreds of companies that roll kernels for their own use and could use a performance boost. (The mainline kernel is NOT where you should look for these improvements first, by the way -- there's a much lower effort required, both in implementation in testing, in special-purpose kernels that need to support a very narrow range of usage. In that sense, looking to "the Linux kernel developers" (by whom I assume you mean the developers who are direct contributors and/or gatekeepers to Linus' and Andrew Morton's kernels) to drive breakthroughs is misguided in most cases.)
The researchers who don't want to do the grunt work required to make a kernel usable for hundreds of thousands of users on dozens of exotic hardware platforms, well, they're doing their job. A different job, that allows them the freedom to break things in dramatic ways on the way to making them dramatically better.
And as much as children can bypass proxy servers and so forth, parents do terrible things in the name of safety that their children are powerless to escape.
Case in point: I heard a lengthy interview with a Canadian couple on the radio this week. They used to live in Toronto, work 9-5 jobs, and have a nice happy life. Then the wife saw a news story about a girl who went missing a few miles from their home, and she followed the coverage over the next couple of days as the girl's body parts were found scattered across the city. So the family moved to a town in BFE with a few hundred residents and no jobs. It's a wonderful place to raise kids, she says. Oh, sure, they have less money, and the father is gone ten months out of the year because he has to commute to the Alberta oil fields, which is a three hour plane ride. When dad is called to work, they wake the kid up at 2:30am to ride with them to the airport, which is a 2 1/2 hour drive. Their marriage is falling apart, and they have to sleep in separate beds when he's home because they're so used to sleeping alone. The kid is having problems because his friends all have (unemployed) dads who come to their birthday parties and little league games.
Would she consider moving back to Toronto? No way, she says. Toronto is too dangerous.
That's child abuse. Now, I'm not saying it should be illegal, or we should force the parents into counseling or anything. It's their choice. But it's abuse.
Dude, just because the Linux kernel guys are rolling out regular upgrades to a real, mature, working kernel that is the basis of a usable, feature-rich operating system does not mean that throwing them at some promising theoretical ideas will magically bring those ideas to your desktop. It might not even speed up the process, and it certainly would result in massive short-term disruption. Linux couldn't accomodate those ideas without a massive ground-up rewrite. Besides, we don't want Linux to live forever, right? How will we shake off our generation's cruft if not by the introduction of a new system whose virtues can't be practically assimilated into Linux?
So the worst case is just doing it the way the UNIX designers intended it to be done in the first place.
The UNIX designers made good use of the "everything is a file" idea, but they didn't apply it dogmatically. They used the idea as a way of generating design ideas for UNIX and discriminating between ideas when one wasn't obviously better by another measure. The results were brilliant, which is why the idea is so valued today, and people continue to apply it. HOWEVER, the original UNIX designers never justified anything obviously lame by saying, "This has a bunch of glaring flaws and seems obviously lame, but it makes everything a file, so we're going to do it anyway." There are lots of things in UNIX that aren't files, because the designers knew that files don't work for everything.
Just to be fair, I should admit that maybe there IS a good way to use files for absolutely everything; still, in the cases where we can't figure out how, it's better to use a non-file interface than to do something we know is stupid. Exposing process data as parseable text through the/proc filesystem is a pretty awesome idea that is very handy for scripting and sysadmin work, but forcing systems programmers to use that interface is awful. It's inconvenient and about as robust as a wet paper bag.
You don't have to know the whole OS to use a Linux system. Everybody understands that the approach with Grandma is not to educate her about niceness levels but to make sure that she never has to use them. In fact, she already doesn't need to use them. They're just a performance tweak for enthusiasts and professionals who want to get around the ordinary performance limitations. Sure, learning some obscure tricks will allow Grandma to get a little bit more out of her hardware, but the same is true under Windows. Normal users just accept the limits of a stock, untweaked system, and experts squeeze out a bit more performance using special tricks.
I'm not sure what problem you have with the situation -- do you want to eliminate the special tweaks so Grandma isn't jealous of the performance her Linux guru friends get out of their systems? Even if you eliminated all flexibility and tweakability from the OS, there would still be overclocking and compiling applications from source and other tricks employed by people with too much time on their hands. This is all bull, of course; it doesn't matter whether there are complicated things in the system that granny will never understand. She doesn't care. She only cares whether it performs well enough for her to do what she wants.
Isn't it better to have government run by people who fear government power over any other fear?
If you magically transported Libertarians into power, they would be worse than anyone else. Bear with me for a minute.
It's easy to be a party of civil liberties when you're out of power. Democrats and Republicans manage it just as well as Libertarians. Remember Republicans going on and on about black helicopters when Clinton was president? Then the Patriot Act -- which included a bunch of prosecutor wish-list items that had nothing to do with terrorism -- was passed on their watch. Clinton wasn't a bad guy, but some of his appointees fell into the trap of believing that they could use direct government power over individuals to stamp out regrettable aspects of our culture. (Actually, they dove into it, enthusiastically, as naturally as if they had been dreaming about it their whole lives.)
Everyone knows better and has known better for hundreds of years, probably much longer It all changes when you actually have power. Power is intoxicating. Libertarians have had less taste of power, and they are pros at thinking they are better, smarter, and more restrained than other people. Their philosophy will not save them.
And what is their philosophy? The less government, the better. Government should stick to the few things that are better handled by government than any other way. People should be free to do whatever they want as long as they're not hurting other people. Guess what? That's exactly what Republicans and Democrats and even the Greens believe. When Libertarians are exposed to real political and policy problems, they will be afflicted by the same shock and malaise that hits idealistic young Republicans and Democratics when they enter politics.
Worse, Libertarians have a clear vision of the world, one that their citizens would not take to quickly. Citizens would be spooked by change and move to thwart the Libertarian reforms. That's when the sensible, moderate Libertarians would lose the support of their party and be replaced by radical, forceful "reeducators." Not something I would want to see.
It's a sublime situation. Hoping to hang on long enough to be rescued (by others or by circumstance), when you have no idea how long it will take, having no possibility of saving yourself, is a different emotional situation and one that belongs in gaming. Beginning a story that way would set a really bleak emotional tone -- but hey, Half-Life 2 set a bleak emotional tone from the beginning, and it wasn't exactly a failure, critically or commercially.
Absolute rules are crutches. Everybody has them, but bragging about them doesn't make any sense. All they do is define your limitations: what the next generation will rebel against.
The problem with Javascript is not linguistic. The problem with Javascript is that turning it on means downloading code from websites and automatically executing it on your machine. Javascript has a few security limitations, but it can change what you see in the browser, alter your HTTP requests, send and receive HTTP requests and responses on your behalf, and other things that are useful for attackers. Bugs are the least of your worries.
No, they didn't, but we really aren't dealing with the same userbase. The number of computer users back then is significantly smaller and more computer savvy than the computer users of today.
Jesus Christ, were you even around back then? Lots of elementary school teachers ended up with an Apple IIe in their classrooms, and they used them. They printed out banners and posters and calendars and newsletters. Many of them used software to manage their grades, and that's a pretty complex kind of application -- setting up classes, setting grading policies, tracking multiple kinds of grades (tests, projects, etc.) It wasn't just one or two tech-savvy teachers, either; almost every teacher who got one started using it for significant useful work. This happened despite the fact that the usual way of providing the computer was to dump it in the classroom with an ImageWriter printer and a free copy of Math Blaster and let the teachers figure it out themselves or learn from each other.
It probably helped that nobody was scared of the Apple IIe. There was a constant drumbeat of propaganda through Apple marketing, Apple II magazines, and Apple II books that Apples were "easy to use" for normal people, unlike the dreaded "PC compatible." As a result, people could sit down with an Apple II and spend an hour figuring something out without getting scared and panicky and deciding it was too hard for them.
Geoff Thompson's a 5th dan black belt in karate (last time I looked), has a bunch of other martial training and spent 10 years working as a bouncer where he ended up fighting for his life on a regular basis.
If he's that good, then I think I was just reading marketing for his book. He probably didn't even write it. Actually, if his experience is as a bouncer, then he definitely didn't write this:
"The enemy we are dealing with today is a cruel one who, like the terminator, has no feelings, no emotion and will not stop until you are down. To deal with a gratuitous enemy we need to employ gratuitous tactics, we need to be attacking first, forget this antiquated block-counter lark, it's not going to happen and if that's what you are being taught now then I feel sorry for you. Be first and ferocious, anything less and youâll be laughed off the planet and then battered."
As a bouncer, that approach would quickly get him sued, fired, and/or prosecuted, not to mention that violent drunks are often way too emotional and you have a decent shot of dealing with them on that level and avoiding violence. (Nobody in his right mind puts himself at gratuitous risk of injury -- or a lawsuit.) So I guess that's just his publisher making a fool of him.
But that's a huge pet peeve of mine. Selling a sense of superiority over people who are in denial and "just don't get it" is something I've never seen a real person do who had both experience and integrity. Everyone (some more than others) has a natural tendency to believe two things: that they have the potential to be spiritually or psychologically superior to everyone else, and that (contrary to all statistics and common sense) in the end life boils down to a violent physical struggle for survival(*). Whenever I see martial arts marketing that exploits those tendencies, I tune it out.
Any martial art that is built on a foundation of distorted thinking (paranoia about crime, etc.) will breed fantasy and belief in unverified techniques. Animal Day (however it works) sounds like a good antidote for that. So, I guess Geoff Thompson is in a constant fight to undo the work of his publisher's marketing department:-)
(*) In a sense this is true, but the struggle is primarily fought indirectly through political and economic levers. Another thing my judo sensei used to say: "It's a very sensible thing to think about how to apply these skills to self-defense, but it's much more likely that judo training will save your life by enabling you to stay calm in a burning building or survive a serious illness [because of better overall health.] If you actually face a reasonable possibility of fighting for your life(**), then for God's sake don't waste your nights here. Go to [the local community college], get a good vocational degree, and move to a better neighborhood. Or even more likely, see a divorce lawyer."
(**) Yeah, he knows about bouncers and police officers. Police officers didn't get this speech (they were typically there to round out an already extensive education); I don't think he ever trained any bouncers.
For a start... There is no such thing. How exactly do I practise breaking someone's neck in "unrestrained competition"?
That's exactly my point. You've never broken a neck. You can't break a neck. You only know of some techniques that, if you had the chance to practice them, would probably result in applicable skill at breaking people's necks. By imposing rules about techniques, sport martial arts allow people to be unrestrained in the amount of speed and power they employ. You're right, it's still a constraint. Practicing with rules can result in people developing blind spots to banned techniques. But at least they learn a few techniques well enough to actually use them.
Yes, I bite, gouge, fish hook, I strike down using my elbow with my full body weight and power on ribs, backs, necks, just anything I can reach.
I assume you mean, "I would bite, gouge, fish hook,...." or "I bite, gouge, fish hook, etc. on something other than a training partner resisting me with 100% effort." If not, well, you're fortunate in what your training partners will put up with.
The timing and dexterity required to do all of those things at full power and speed can only be developed by repeated practice at full power and speed. Not by taking advantage of one or two lucky chances to try things in real life -- not by practicing at lower power or speed to protect your partner. It takes hundreds of tries to learn to hit a real, moving person with a decent punch; why in the world would you think small joint manipulation or grabbing the clavicle is any different?
Granted, if I were ever in a real fight (which is a damn small possibility, but anyway) I'd try whatever seemed to give me an advantage, but I'd rely mostly on things I learned when I studied judo. I know judo is an insanely restrained "martial art", if you can even call it that (since nobody gives a damn about anything except the competition-legal techniques), and I know that the techniques as a studied them were optimized for competition, not street fighting, but hey, I know those techniques.
I know what it took to learn those skills: First practicing throws with a stationary passive partner, then practicing with a moving passive partner in movement drills, then low-speed, low-effort randori, and then playing to win. I know that you learn a technique better and better at each stage, and I know that a technique actually feels different at each stage. I know that it takes waaay more practice to go from the half-speed semi-cooperative randori to full-speed, full-effort competition. I know that twenty pounds or a few inches of height makes a HUGE difference in how hard an opponent is to throw -- you can feel damn good about your technique practicing against a 6' 170 lb guy, and then you go against a 5'10" 190 lb guy and suddenly you're like, "Umm, sensei, I think I'm doing something wrong here." And I know that going up against a guy who's a lot faster than me makes pretty much everything I do look like complete shit.
So I know that I have a snowball's chance in hell of ever successfully executing a technique in a real fight unless I've done it a hundred times at full power and full speed in practice first. (Hell, it's been a few years, so even my best throw (uchi mata) would be pretty sloppy, but that's another issue.)
Actually, that's the most important point of my post, so I'll say it again: Through lots and lots of experience, I know that I have very little chance of successfully executing a technique in a real fight unless I've done it in practice a hundred times at full power and full speed, against a real opponent. If I can hit the guy with slop, then he never posed much of a threat to begin with.
Now we have that out of the way, I agree, the more realistic the training the better the practitioner will perform. Hence things like "Animal Day". And other forms of non compliant training.
The practice of making simplifying assumptions is mainly a problem when modeling performance. In this case, the guy was just describing the calculations that his code made. You don't have to model every aspect of behavior to model some aspects rigorously. Math bugs in microprocessors aside, I can't think of any reason why he would have needed to compromise rigor. (A typical mistake here would have been to ignore some limitations of computer arithmetic, but the limitations of computer arithmetic were central to the problem he was trying to solve, so I bet he took them into account.)
Undefined language semantics and other kinds of unknowables limit what you can model mathematically, but your code will only work reliably if you can avoid dependence on such things. The only good reasons to avoid a mathematical approach are sheer intractability and insignificance of the product, and a process scheduler is 1) not that complex, and 2) definitely important enough to merit a mathematical approach.
I suspect what we need in cases like this is for everyone who wouldn't have know about this except through Slashdot to just STFU and GTFA. So, err, this will be my last post in this thread:-)
Math is reliable, but it's slow going, even for very simple math.
People prefer verbal reasoning, even though all kinds of logical errors can slip in undetected, for the simple fact that they can read it at the speed of speech -- even if they really shouldn't.
This is PAINFULLY evident in the software world. I imagine even kernel developers tend to be lazy this way.
The martial arts... Karate, Kung-fu, ju-jitsu and the rest were never designed as competitive sports. They were self defence systems. And they were and are brutally effective if trained and practised that way.
These days, discounting war zones and Brazilian slums where even the Gracies wouldn't go, the only people who get to train at all are the ones who do so under rules designed to prevent death and serious injury. A technique that isn't practiced and polished in actual use is worthless, so the professional MMA fighters are doubtless the most brutally effective fighters in the world. Who's going to do better against a mugger who has been in his share of scuffles: a martial arts "practitioner" trying to execute a deadly technique that he has only simulated and never actually performed, or an MMA fighter executing mundane non-deadly punches and kicks that he has polished through hundreds of hours of practice against trained, uncooperative opponents?
Sport styles are not the antithesis of practical self-defense styles; they are the practical self-defense styles. Everything else is just exercise, spiritual discipline, and/or cultural tourism. Techniques that can't be practiced in balls-out unrestrained competition against friend and foe alike are dead techniques like Latin is a dead language.
Well, if my kung fu education based on bruce lee movies serves, they have all renounced violence and are living in remorse for all the lives they've taken
Then we'll know the "War Against Terror" is working when we see a bunch of guys named Muhammed performing kung-fu for tourists.
Slashdot Mirror
Having a great university system is the main force slowing outsourcing. Many of the most talented foreigners come to the US for education, and most who can stay, stay. Imagine how outsourcing would be galloping along if all the foreign workers and foreign professors in the US had stayed home and built up the tech industries in their home countries instead of coming here.
You know, somebody who read the rest of the thread and didn't read the article summary would think you were posting off-topic, because nobody else is talking about user experience. I guess it never occurred to anyone else.
Commercial web sites must put customer experience near the bottom when it comes to mapping, because I mostly see second-rate map links on company web sites. Even image-sensitive brick-and-mortar business like restaurants usually provide crude and unusable maps. Every prospective customer needs to know how to get to a restaurant. Restaurants depend on trendiness and/or friendliness, usually both. Google works; it's available; supposedly there are other decent options, too. What's the hold up? How long will it take before I can go to the web site of a nice restaurant in my city and have even odds of getting a usable map?
This is true but not worth much. Software purchases usually go wrong because of mistakes made by the customer, not the vendor. The vendor delivers the software as promised, and it turns out to be subtly incompatible with your needs, or integration turns out to be insanely expensive. Then how do you get your money back? You'll certainly never get back the money you invested in services and integration. You're stuck with a solution that's much more costly or less functional than envisioned and possibly even worse than you had before.
Then the money you paid comes back to haunt you, because irrationality (not to mention very rational political considerations by management) creates a very powerful bias in favor of persisting on the failed path. Even if your company doesn't renew the software licenses year after year (which is common enough with failed software purchases,) you'll still be pressured to use the system for a while so it looks like the money wasn't wasted. Even if the solution is shelfware, the mere fact that money changed hands can mean that you are forbidden to pursue alternatives. (At least officially -- inevitably, Perl scripts or Office macros proliferate like weeds on an abandoned construction site, until your company is dependent on a whole bunch of software most of which you don't even know exists.)
When no money has changed hands (merely hours and hours of expensive labor,) it's politically feasible to fall back on an old solution and spin the failed project as an experiment. It's acceptable to simply stop running a server that nobody uses, because turning it off is not seen as a symbolic declaration of some executive's failure.
Granted, it's not as cut-and-dried as all that. If the cost of your investment in a new OSS solution is well understood, then you might have the same problem throwing it away as you would with a purchased system. Your odds are much better when nothing is purchased, though, even if only for psychological reasons. And, of course, you also have the option to make modifications to the software and support it yourself. (Sometimes a trivial change is all it takes, but is Microsoft going to make a trivial change for you and risk a regression?)
All in all, the only thing a software purchase buys you is a commitment to make the product work as advertised, which is rarely a problem with commercial or OSS software from a reputable source. It doesn't cover analysis mistakes on your part, no matter how much the vendor encouraged you to make them.
Yep, I'm looking at my coworkers and seeing more people with active fantasy lives than with the guts to kiss a coworkers. Freakin' liars. I'm asleep every day from 1:00 to 2:00. Most days my eyes are open and I'm typing during that time. That's my "make mistakes so I can learn from them" time. I'm also a stone-cold ladykiller, but I've never kissed a coworker. Had a chance to, once, but she was drunk and I was chivalrous. The chivalry was wasted, but it wasn't a costly mistake.
Java did not go far from the plain old mutex, lock, and condition variable paradigm. Java's version is almost as flexible and a lot easier for beginners to understand, and Java steers beginners away from incorrectness (towards slowness, but that's the right direction for beginners.) It's still not so different from "raw" threading using POSIX, just more elegantly expressed. Outside Java, everyone is still doing "raw" threading in all of the popular languages, while various less-popular languages such as Erlang and Scala(*) experiment with radically different approaches. When the hammer starts to come down and more and more J. Random Codemonkeys have to take advantage of multicore processors or lose their jobs, there will be a big migration to one or more languages that make threading as easy as possible. I think that's what he's talking about when he says Python should be "the multi-processing language."
(*) People are stubborn in their prejudices and have already categorized Erlang and Scala as being "too hard" or "weird" or "languages for smart people." Even if Erlang, Scala, or another language has already nailed the next generation of threading concepts, people will wait for them to appear in a language with comfortable, low-brow marketing that assures them they won't fail to make the leap. The only thing Python has going against it is that many very smart people like Python -- HPC scientists use it to wrangle Fortran libraries, ESR famously praised it, it's popular in Google for scripting, and IIRC even Peter Norvig has said some kind words about it. Hopefully that doesn't doom it, because most of those people praise it for being less intellectually taxing than its similarly-powerful competitors.
I'm making a distinction between piecework hacks and systematic exploitation of these ideas. You're thinking on a much smaller scale than your first earlier implied (since you first referred the ideas in their most general form), and I think if I understand you now I don't necessarily disagree. Also, with respect to this particular example you're talking about correctness vs. cruft, which is an entirely separate argument.
That is rocket science, in the sense that some kind of security model would have to be enforced to prevent malicious or careless users from borking the kernel. To avoid the overhead of constant checking, the security check would have to be done on the code itself when it is presented by the user, rather than on the code's runtime activity. The rocket science comparison here is particularly apt, since it's an old idea, has been demonstrated in practice, is routine for some uses (rockets take satellites into orbit; Java checks loaded bytecode to make sure it's safe for the VM), yet it is still only practical (so far) in a narrow range of applications. A DSL is much easier, because it can include a very limited set of abstractions and control flow facilities (or no flow control facilities at all.)
In other words, the standard argument for processes over threads is pretty much the same as the (primary) one Linus uses for C over C++: If you use threads/C++ then you're going to do all kinds of stupid complicated things and doom yourself. If you use processes/C then you'll magically see all the simple designs that you overlooked when you were using threads/C++, because you have no choice. That isn't universally true; not everybody is frothing at the mouth to do all the nasty complicated things their tools allow.
It isn't crack. Making it available isn't the same as chaining people to it.
For another example, you can combine multiple system calls into one by defining lots of "combo" system calls. That's kind of an atrocity, but it might be worth it in a few especially critical places. Evidently Linux is getting along okay without it. Alternatively, you could hide the functionality in the platform somehow at the linguistic or linking level. That's what I'm talking about when I say a massive reworking would be required.
They're "only good at copying" because they refuse to copy the "demonstrated benefits" achieved by researchers? I guess that would be insulting if it were coherent.
Demonstrating a performance improvement is only the first step in development. Researchers don't put their products through QA and deploy them to hundreds of thousands of users on dozens of platforms. Nor do they take on responsibility for maintaining their hacks through further changes and enhancements. Taking on that responsibility is not simply "copying."
The Linux kernel is open-source and is often used for kernel research. Anyone who makes improvements that are suitable for inclusion in the kernel are free to do so. If the kernel team doesn't accept them, then they're free to hire themselves out to Oracle or an embedded Linux company or any one of the hundreds of companies that roll kernels for their own use and could use a performance boost. (The mainline kernel is NOT where you should look for these improvements first, by the way -- there's a much lower effort required, both in implementation in testing, in special-purpose kernels that need to support a very narrow range of usage. In that sense, looking to "the Linux kernel developers" (by whom I assume you mean the developers who are direct contributors and/or gatekeepers to Linus' and Andrew Morton's kernels) to drive breakthroughs is misguided in most cases.)
The researchers who don't want to do the grunt work required to make a kernel usable for hundreds of thousands of users on dozens of exotic hardware platforms, well, they're doing their job. A different job, that allows them the freedom to break things in dramatic ways on the way to making them dramatically better.
And as much as children can bypass proxy servers and so forth, parents do terrible things in the name of safety that their children are powerless to escape.
Case in point: I heard a lengthy interview with a Canadian couple on the radio this week. They used to live in Toronto, work 9-5 jobs, and have a nice happy life. Then the wife saw a news story about a girl who went missing a few miles from their home, and she followed the coverage over the next couple of days as the girl's body parts were found scattered across the city. So the family moved to a town in BFE with a few hundred residents and no jobs. It's a wonderful place to raise kids, she says. Oh, sure, they have less money, and the father is gone ten months out of the year because he has to commute to the Alberta oil fields, which is a three hour plane ride. When dad is called to work, they wake the kid up at 2:30am to ride with them to the airport, which is a 2 1/2 hour drive. Their marriage is falling apart, and they have to sleep in separate beds when he's home because they're so used to sleeping alone. The kid is having problems because his friends all have (unemployed) dads who come to their birthday parties and little league games.
Would she consider moving back to Toronto? No way, she says. Toronto is too dangerous.
That's child abuse. Now, I'm not saying it should be illegal, or we should force the parents into counseling or anything. It's their choice. But it's abuse.
Dude, just because the Linux kernel guys are rolling out regular upgrades to a real, mature, working kernel that is the basis of a usable, feature-rich operating system does not mean that throwing them at some promising theoretical ideas will magically bring those ideas to your desktop. It might not even speed up the process, and it certainly would result in massive short-term disruption. Linux couldn't accomodate those ideas without a massive ground-up rewrite. Besides, we don't want Linux to live forever, right? How will we shake off our generation's cruft if not by the introduction of a new system whose virtues can't be practically assimilated into Linux?
The UNIX designers made good use of the "everything is a file" idea, but they didn't apply it dogmatically. They used the idea as a way of generating design ideas for UNIX and discriminating between ideas when one wasn't obviously better by another measure. The results were brilliant, which is why the idea is so valued today, and people continue to apply it. HOWEVER, the original UNIX designers never justified anything obviously lame by saying, "This has a bunch of glaring flaws and seems obviously lame, but it makes everything a file, so we're going to do it anyway." There are lots of things in UNIX that aren't files, because the designers knew that files don't work for everything.
Just to be fair, I should admit that maybe there IS a good way to use files for absolutely everything; still, in the cases where we can't figure out how, it's better to use a non-file interface than to do something we know is stupid. Exposing process data as parseable text through the
You don't have to know the whole OS to use a Linux system. Everybody understands that the approach with Grandma is not to educate her about niceness levels but to make sure that she never has to use them. In fact, she already doesn't need to use them. They're just a performance tweak for enthusiasts and professionals who want to get around the ordinary performance limitations. Sure, learning some obscure tricks will allow Grandma to get a little bit more out of her hardware, but the same is true under Windows. Normal users just accept the limits of a stock, untweaked system, and experts squeeze out a bit more performance using special tricks.
I'm not sure what problem you have with the situation -- do you want to eliminate the special tweaks so Grandma isn't jealous of the performance her Linux guru friends get out of their systems? Even if you eliminated all flexibility and tweakability from the OS, there would still be overclocking and compiling applications from source and other tricks employed by people with too much time on their hands. This is all bull, of course; it doesn't matter whether there are complicated things in the system that granny will never understand. She doesn't care. She only cares whether it performs well enough for her to do what she wants.
Thanks for the link.
If you magically transported Libertarians into power, they would be worse than anyone else. Bear with me for a minute.
It's easy to be a party of civil liberties when you're out of power. Democrats and Republicans manage it just as well as Libertarians. Remember Republicans going on and on about black helicopters when Clinton was president? Then the Patriot Act -- which included a bunch of prosecutor wish-list items that had nothing to do with terrorism -- was passed on their watch. Clinton wasn't a bad guy, but some of his appointees fell into the trap of believing that they could use direct government power over individuals to stamp out regrettable aspects of our culture. (Actually, they dove into it, enthusiastically, as naturally as if they had been dreaming about it their whole lives.)
Everyone knows better and has known better for hundreds of years, probably much longer It all changes when you actually have power. Power is intoxicating. Libertarians have had less taste of power, and they are pros at thinking they are better, smarter, and more restrained than other people. Their philosophy will not save them.
And what is their philosophy? The less government, the better. Government should stick to the few things that are better handled by government than any other way. People should be free to do whatever they want as long as they're not hurting other people. Guess what? That's exactly what Republicans and Democrats and even the Greens believe. When Libertarians are exposed to real political and policy problems, they will be afflicted by the same shock and malaise that hits idealistic young Republicans and Democratics when they enter politics.
Worse, Libertarians have a clear vision of the world, one that their citizens would not take to quickly. Citizens would be spooked by change and move to thwart the Libertarian reforms. That's when the sensible, moderate Libertarians would lose the support of their party and be replaced by radical, forceful "reeducators." Not something I would want to see.
It's a sublime situation. Hoping to hang on long enough to be rescued (by others or by circumstance), when you have no idea how long it will take, having no possibility of saving yourself, is a different emotional situation and one that belongs in gaming. Beginning a story that way would set a really bleak emotional tone -- but hey, Half-Life 2 set a bleak emotional tone from the beginning, and it wasn't exactly a failure, critically or commercially.
Absolute rules are crutches. Everybody has them, but bragging about them doesn't make any sense. All they do is define your limitations: what the next generation will rebel against.
The problem with Javascript is not linguistic. The problem with Javascript is that turning it on means downloading code from websites and automatically executing it on your machine. Javascript has a few security limitations, but it can change what you see in the browser, alter your HTTP requests, send and receive HTTP requests and responses on your behalf, and other things that are useful for attackers. Bugs are the least of your worries.
Jesus Christ, were you even around back then? Lots of elementary school teachers ended up with an Apple IIe in their classrooms, and they used them. They printed out banners and posters and calendars and newsletters. Many of them used software to manage their grades, and that's a pretty complex kind of application -- setting up classes, setting grading policies, tracking multiple kinds of grades (tests, projects, etc.) It wasn't just one or two tech-savvy teachers, either; almost every teacher who got one started using it for significant useful work. This happened despite the fact that the usual way of providing the computer was to dump it in the classroom with an ImageWriter printer and a free copy of Math Blaster and let the teachers figure it out themselves or learn from each other.
It probably helped that nobody was scared of the Apple IIe. There was a constant drumbeat of propaganda through Apple marketing, Apple II magazines, and Apple II books that Apples were "easy to use" for normal people, unlike the dreaded "PC compatible." As a result, people could sit down with an Apple II and spend an hour figuring something out without getting scared and panicky and deciding it was too hard for them.
But that's a huge pet peeve of mine. Selling a sense of superiority over people who are in denial and "just don't get it" is something I've never seen a real person do who had both experience and integrity. Everyone (some more than others) has a natural tendency to believe two things: that they have the potential to be spiritually or psychologically superior to everyone else, and that (contrary to all statistics and common sense) in the end life boils down to a violent physical struggle for survival(*). Whenever I see martial arts marketing that exploits those tendencies, I tune it out.
Any martial art that is built on a foundation of distorted thinking (paranoia about crime, etc.) will breed fantasy and belief in unverified techniques. Animal Day (however it works) sounds like a good antidote for that. So, I guess Geoff Thompson is in a constant fight to undo the work of his publisher's marketing department :-)
(*) In a sense this is true, but the struggle is primarily fought indirectly through political and economic levers. Another thing my judo sensei used to say: "It's a very sensible thing to think about how to apply these skills to self-defense, but it's much more likely that judo training will save your life by enabling you to stay calm in a burning building or survive a serious illness [because of better overall health.] If you actually face a reasonable possibility of fighting for your life(**), then for God's sake don't waste your nights here. Go to [the local community college], get a good vocational degree, and move to a better neighborhood. Or even more likely, see a divorce lawyer."
(**) Yeah, he knows about bouncers and police officers. Police officers didn't get this speech (they were typically there to round out an already extensive education); I don't think he ever trained any bouncers.
That's exactly my point. You've never broken a neck. You can't break a neck. You only know of some techniques that, if you had the chance to practice them, would probably result in applicable skill at breaking people's necks. By imposing rules about techniques, sport martial arts allow people to be unrestrained in the amount of speed and power they employ. You're right, it's still a constraint. Practicing with rules can result in people developing blind spots to banned techniques. But at least they learn a few techniques well enough to actually use them.
I assume you mean, "I would bite, gouge, fish hook, ...." or "I bite, gouge, fish hook, etc. on something other than a training partner resisting me with 100% effort." If not, well, you're fortunate in what your training partners will put up with.
The timing and dexterity required to do all of those things at full power and speed can only be developed by repeated practice at full power and speed. Not by taking advantage of one or two lucky chances to try things in real life -- not by practicing at lower power or speed to protect your partner. It takes hundreds of tries to learn to hit a real, moving person with a decent punch; why in the world would you think small joint manipulation or grabbing the clavicle is any different?
Granted, if I were ever in a real fight (which is a damn small possibility, but anyway) I'd try whatever seemed to give me an advantage, but I'd rely mostly on things I learned when I studied judo. I know judo is an insanely restrained "martial art", if you can even call it that (since nobody gives a damn about anything except the competition-legal techniques), and I know that the techniques as a studied them were optimized for competition, not street fighting, but hey, I know those techniques.
I know what it took to learn those skills: First practicing throws with a stationary passive partner, then practicing with a moving passive partner in movement drills, then low-speed, low-effort randori, and then playing to win. I know that you learn a technique better and better at each stage, and I know that a technique actually feels different at each stage. I know that it takes waaay more practice to go from the half-speed semi-cooperative randori to full-speed, full-effort competition. I know that twenty pounds or a few inches of height makes a HUGE difference in how hard an opponent is to throw -- you can feel damn good about your technique practicing against a 6' 170 lb guy, and then you go against a 5'10" 190 lb guy and suddenly you're like, "Umm, sensei, I think I'm doing something wrong here." And I know that going up against a guy who's a lot faster than me makes pretty much everything I do look like complete shit.
So I know that I have a snowball's chance in hell of ever successfully executing a technique in a real fight unless I've done it a hundred times at full power and full speed in practice first. (Hell, it's been a few years, so even my best throw (uchi mata) would be pretty sloppy, but that's another issue.)
Actually, that's the most important point of my post, so I'll say it again: Through lots and lots of experience, I know that I have very little chance of successfully executing a technique in a real fight unless I've done it in practice a hundred times at full power and full speed, against a real opponent. If I can hit the guy with slop, then he never posed much of a threat to begin with.
The practice of making simplifying assumptions is mainly a problem when modeling performance. In this case, the guy was just describing the calculations that his code made. You don't have to model every aspect of behavior to model some aspects rigorously. Math bugs in microprocessors aside, I can't think of any reason why he would have needed to compromise rigor. (A typical mistake here would have been to ignore some limitations of computer arithmetic, but the limitations of computer arithmetic were central to the problem he was trying to solve, so I bet he took them into account.)
Undefined language semantics and other kinds of unknowables limit what you can model mathematically, but your code will only work reliably if you can avoid dependence on such things. The only good reasons to avoid a mathematical approach are sheer intractability and insignificance of the product, and a process scheduler is 1) not that complex, and 2) definitely important enough to merit a mathematical approach.
I suspect what we need in cases like this is for everyone who wouldn't have know about this except through Slashdot to just STFU and GTFA. So, err, this will be my last post in this thread :-)
Math is reliable, but it's slow going, even for very simple math.
People prefer verbal reasoning, even though all kinds of logical errors can slip in undetected, for the simple fact that they can read it at the speed of speech -- even if they really shouldn't.
This is PAINFULLY evident in the software world. I imagine even kernel developers tend to be lazy this way.
These days, discounting war zones and Brazilian slums where even the Gracies wouldn't go, the only people who get to train at all are the ones who do so under rules designed to prevent death and serious injury. A technique that isn't practiced and polished in actual use is worthless, so the professional MMA fighters are doubtless the most brutally effective fighters in the world. Who's going to do better against a mugger who has been in his share of scuffles: a martial arts "practitioner" trying to execute a deadly technique that he has only simulated and never actually performed, or an MMA fighter executing mundane non-deadly punches and kicks that he has polished through hundreds of hours of practice against trained, uncooperative opponents?
Sport styles are not the antithesis of practical self-defense styles; they are the practical self-defense styles. Everything else is just exercise, spiritual discipline, and/or cultural tourism. Techniques that can't be practiced in balls-out unrestrained competition against friend and foe alike are dead techniques like Latin is a dead language.