Hmm. I suppose Texas isn't all that civilized, then. Deadly force is authorized here:
(B) to prevent the other's imminent commission of aggravated kidnapping, murder, sexual assault, aggravated sexual assault, robbery, or aggravated robbery.
Also, in protection of property:
(A) to prevent the other's imminent commission of arson, burglary, robbery, aggravated robbery, theft during the nighttime, or criminal mischief during the nighttime; or
(B) to prevent the other who is fleeing immediately after committing burglary, robbery, aggravated robbery, or theft during the nighttime from escaping with the property...
Yup, anything as far down as protecting ones' property from criminal mischief at night is grounds for use of deadly force here (if the property owner reasonably believes that he would be putting himself at risk were he to use an alternate approach) -- and I think that's fine.
Simply put: I don't care if burglars or rapists -- or even those who knowingly harm others' property -- are people or not; their actions threaten the safety, wellbeing and personal freedoms of others. These people are most certainly *not* part of the "civilized society" of which you speak, and I see no need to place their lives as more important than the ability of those whom they would victimize to defend themselves.
One major vote fraud technique was "chain voting," where a wily precinct captain would obtain a blank punch card, often by securing an absentee ballot, and punch in the "right" votes. He would then give the prepunched card to a voter -- sometimes solicited off the street with a few bucks or a bottle of cheap wine -- have him go in to vote, drop the prepunched card in the box on the way out and hand the precinct captain another unpunched card. The "chain" could go on all day, as long as cooperating voters could be found and friendly election judges didn't examine things too closely.
*ponder*...
If the box the punched cards are dropped into is specific to the machine (such that the machine can have an optical scanner to look for a barcode on the cards inserted to the box), that's fixable by detecting when cards created during one voting session are used in another.
Of course, this means that we're trusting the machine (bad bad bad!) and introduces potential for false-positive detection scenarios. Even detecting such fraud without taking action on it is useful, however, as it permits a threat of legal followup on any such fraud -- and thus decreases the probability of it occuring -- even if no suspect ballots are actually discarded.
By the way, one issue: Banking and voting are utterly dissimilar, because banking doesn't have the same anonymity requirements. The bank can record who it was that sat at the ATM and punched in a request for a given transaction, and consequently can maintain a verifiable audit trail; the voting machine can't. This makes their security constraints entirely dissimilar.
While Linux itself isn't necessarily tremendously innovative, a lot of the stuff being built on top of it is quite so.
Look at LUFS's sshfs module for an example. Yes, userspace filesystems are old hat to anyone who'se worked with a *real* microkernel OS (no, NT doesn't count) -- but allowing unpriveleged users to mount other machines' filesystems with nothing more than ssh access to the remote box is indeed pretty damn innovative.
Another little tool (not necessarily written *just* for Linux) that strikes me as innovative in the extreme: slirp. (If you don't know what it is, go look it up).
Another innovative linux-based project: User-mode linux. (If you're coming from elsewhere, I'll give a rough synopsis: UML makes it very easy to set up fully isolated sandboxes and virtual servers sharing preexisting hardware; permits "kernel debugging" to be done with regular userspace debugging tools; and has far better security and isolation guarantees than most of the convential virtual server mechanisms. I've additionally used it for creating virtual sandboxed networks when trying to reverse-engineer or observe behaviour of hostile code).
These are just things coming off the top of my head. Generally speaking, though: I won't necessarily claim that Linux *itself* is innovative -- but there are a whole lot of people doing innovative things on *top* of Linux.
Software and books are both protected by the same basic copyright laws. Software is frequently *also* protected by a license -- but that license has to be enforcable in and of itself to have any effect. The basic legal protection for software, like books, is copyright; and unless a EULA, in and of itself, meets all the requirements for an enforcable contract (including granting the user consideration -- giving them some right or privilege they didn't have before).
Here's a question for you: I go over to Bob's Software House. I pay Bob $30 for a copy of a program he wrote. There's no license agreement, before or after purchase. What did I just buy?
Answer: I bought a piece of software. Note that the word is "bought" -- not "licensed"; I didn't put down my $30 and sign a licensing agreement, but rather a purchasing agreement. There's substantial legal precedent on point that any activity having the form of a sale is, in fact, a sale itself. Anything else is as silly as claiming that a car dealership can claim that, in fact, you're really just leasing the car you just paid for.
What can I do with it? Use it in any way that doesn't violate copyright. I can't distribute copies or make derivative works -- but for my $30 I can run the software on my computer or make a model aircraft out of it.
Now, let's say I already bought this software, our purchase is concluded, then Bob comes over to my house with a contract he wants me to sign that restricts what I can do with the product I purchased from him beyond the limitations of copyright law. Keep in mind that this contract was not a condition of purchase, and that I already own the copy he sold me.
Two questions are raised:
- Do I have to sign? - Is the contract even valid, if I do sign?
The answer to the first contract is an obvious no -- I'm under no obligation to sign; I already purchased the software, it is my property and I have the ability to take any action with it which is not prohibited by law.
The answer to the second question is a bit more questionable. A valid contract needs to provide, among other things consideration -- both parties must benefit. If this "contract" only restricts the set of things I can do without providing me with some benefit or placing Bob under some obligation, even if I sign it is void and unenforcable.
BTW: The only restrictions against modifying software you bought (barring a valid contract in place that changes this bargain) are the restrictions against preparation of derivative works -- the exact same law that applies to books. There *are* some recent laws on point regarding reverse engineering, yes -- but those protect it (for purposes of interoperability engineering, for instance) as well as making it illegal under certain circumstances.
Also: What I said above doesn't apply to every state in the Union -- but it applies to most of them. I'm not a lawyer (and indeed, when I was taking contract law, my professor disagreed with me on some of what I'm saying here -- but IP wasn't his field, and there are more than a few real lawyers who do agree with me on those disputed points).
Finally: If you respond to this post, please include your operating legal theory on precicely what rights one has after purchasing the software from Bob's without a license.
Eh? You don't need a license to use software any more than you need a license to read a book. You need a license to reproduce a book (or software), or for the other things limited by copyright (public performance or display, preparation of derivative works, etc)... but *usage* isn't part of that set.
Granted, the argument has been made that "using" software necessarily involves copying it -- but IIRC, some recent laws have clarified that argument out of existance.
I am soon expecting virus writers to plan for the inevitable clean fixes from Symantec and such and, using predictive behavior, ensure that a user can't clean his or her system.
Nothing new about that. Remember the viruses that would encrypt a user's files -- such that after the virus was cleaned, all the files it had touched became inaccessible?
Plenty of folks here have already pointed out how easy Debian makes automatic updates, so I won't go into that.
As for Red Hat (formerly) having unnecessary services exposed out-of-the-box -- yup, that's a vendor problem. You'll notice I didn't say anything about the "M" word in my case, but referred to "the vendor" in general.
I'm responsible for the security of the deployment configuration of my company's product, so the words I spoke up there apply to me, as much as anyone else. If I ship something that exposes anything but the most absolutely critical services, I'm to blame. If the user prevents the automatic updates from functioning (because in this product, its update -- and offsite backup -- facility is *enabled* by default), they're to blame. I wasn't bashing Microsoft -- I was stating my beliefs regarding the line between user responsibility and vendor responsibility in general.
And by the way, I wonder as to whether you've ever been in a case where you're locked in to a vendor that suddenly decides to charge you $30K for the next version -- don't buy it, no updates (or support renewals) for you -- which can be more than just a minor annoyance if (say) the huge chunk of in-house software you run your business off of was written around the thing. (Not that I'd have been in a situation like that myself once. Nope, not me. *cough*).
Vendor lock-in sucks, and in a very, very big way -- especially if you don't have the groundwork in place to be able to switch. Even just being able to say that you're capable of moving to a competitor means, at a minimum, far better negotiating terms. Likewise, being fluent with a number of vendors' products comes in handy when you're looking into work and are able to say "yes, I can do that" -- or for the better understanding that such a broader skillset provides.
And while I'm rambling, one last thing: I'm not really fond of Red Hat, but I'm pretty damn sure that their installers at least *used* to support an "upgrade" option that would Do The Right Thing -- and this was around Red Hat 5 and 6.x, so I'd be pretty damn suprised if they didn't still have that functionality today.
It'd be ideal if everyone could drop everything and IT could tell everyone to reboot all systems for a patch for a bug that needs to be deployed, but that just ain't generally the case.
Needing to reboot the whole bloody system to apply any but the most core (ie. tcp stack) security patches is pretty damned broken, too.
2. The system's default configuration made almost everyone vulnerable being attacked via the bug, even if the user isn't actually making use of the buggy service.
On item [1], yes, there's a really strong argument that it's the user's fault. On item [2], though, it's pretty damn clearly the vendor's negligence.
And they only started doing this under pressure from people who figured out what was going on.
Really, now? And I suppose they only stopped carrying graphical ads when folks complained, right? (Hint: Google's advertising was clearly deliniated from Day 1 -- I've been using it since before they had ads at all, and have no clue whatsoever wtf you're talking about).
Not all companies are soulless -- they just look that way when you're wearing your cynic-colored glasses. I've been at a few engineering-driven companies (one of which, sadly, *stopped* being engineering-driven partway through my tenure) and there really are places where decisions are made based on making a product that we (the engineers making the thing) would personally want to buy, and treating our customers the way we expect to be treated ourselves.
Of course, some of the $@#%^ marketing and strategic-management slimeballs *do* have a tendency to come in and mess all that up in the effort to make a quick buck... but they're not everywhere. "All" companies aren't soulless -- unless you insist on looking at them that way.
It's *waaaay* worse than that for doctors. I work for a medical software startup, and two of the head honchos are MDs (one an ER surgeon, the other a general practitioner). Not only are their student loans frequently a whole lot bigger than that, but malpractice insurance starts on the area of $70-150k/year for a doctor with a perfectly clean record (more for neurosurgeons and other folks in sensitive specialties). They've mentioned patients dying in smaller communities around here because there was no neurosurgeon available anywhere they could fly them to in time because nobody can afford to be in the business -- the malpractice rates are just too high (and *that* is largely the case because of the huuuge damages that often get awarded when a MD screws up).
So yes, it's a mess, and people really *are* dying because of it. *sigh*.
I'm in Texas, though. I don't know what it's like right now in California.
Proper disaster planning involves both minimization of the likelihood of failures *and* minimization of the impact of the failures that occur anyways. Having either without the other just ain't good enough -- one way you have frequent failures (but prevent really massive problems from resulting) and the other way the rare failures that get by anyhow are downright disasterous.
"setting up a strawman" -- creating a false version of your opponent's argument that you could knock down easily.
My employer is a stealth-mode startup; I can't talk about what we do. Unlike my last job (at MontaVista Software), our product isn't open source -- but several of our components and tools are, and we've contributed some patches back.
As for reusability, *shrug* -- it depends. I've found stuff like DB access layers (and frameworks -- see Struts for a good example) to really be quite reusable when done correctly. For that matter, though, my current personal project was able to save hundreds if not thousands of lines by reusing the parser and related framework from Checkstyle (which is extended to keep token location information accessible from the AST). Of course, that wouldn't be possible if Checkstyle weren't designed so well.
On past projects, likewise, I've been able to really, truly and succesfully put multiple frontends to a single backend written without knowledge of any of them. This last bit is key -- if I'd been writing the backend while writing a frontend to drive it (other than the test harness), my backend probably really *would* have ended up tied to that frontend -- or at least needing changes to work elsewhere.
BTW, I'd argue that there do exist methods for creating solid-as-a-bridge software. Look at Knuth and his creation of mathematical proofs for the algorithms he uses -- and look at just how solid TeX has been in the years since he wrote it.
As for never seeing reusability work well beyond STL, I'd strongly advise that, should the opportunity become available, you try something other than C++. Personally I favor Python -- its introspection layer permits functionality that would just be unthinkable or could require 10-20x more code elsewhere (for instance, a paint program I wrote back in school in Jython implemented the following functionality in less characters than I'm taking to describe it: "look at the static members of java.awt.Color; find all which are instances of java.awt.Color and add them to a list of colors available to the user and to a mapping of known colors to the colors' names"). I'd call this reusability, after a fashon -- I'm reusing the list of colors in java.awt.Color, in a manner the creators of this class never expected. Java, for all its warts (of which it has fewer now than before -- as of 1.4 it has an equivalent to the select() call, and 1.5 will have some substantial language-level improvements) has a very large amount of reusable 3rd-party code available, making it frequently possible to avoid any more work than necessary writing things other than core business logic. Take a look at the Jakarta suite of libraries, frameworks and tools (particularly Struts and Torque) for an example of the goodies available to folks looking for reusable components for larger-scale projects.
I'm also hopeful for.net after it and related projects (Mono) have had some time to mature... but in mentioning those I've wandered *very* far off topic indeed.
Dunno, though -- I'm (strongly) guessing that these folks are suffering from configuration issues more than anything else. A release candidate, after all, is something which actually *could* become the.0 release (unless, of course, you're Linus... *sigh*).
As a result, a RC generally won't have known issues large enough to prevent release -- because if it had such known issues, it wouldn't be eligable for.0 designation. A few scenarios, therefore, present themselves:
1. The folks complaining about Samba 3.0 here had severe configuration issues (failure to RTFM).
2. The folks complaining about Samba 3.0 here are basing their complaints from a release *prior* to the release candidate.
3. The folks complaining about Samba 3.0 here are hitting bugs obscure enough that the maintainers didn't know about them when deciding to make this a RC release.
4. The folks complaining about Samba 3.0 here are hitting bugs minor enough that the maintainers are willing to release with them in place.
No doubt the truth is a mix of these -- but I'm guessing that a strong majority of issues encountered will be of the former two varieties.
Depends on the team. What some people release as "just an RC" others release as final and still others hold back as alpha or beta. Saying "release candidates are always garbage" takes nothing into account wrt the release management style of the programming team in question.
Now, if you had something to say about the quality of the Samba team's RC releases in particular, that'd be worthwhile -- but given how long the Samba 3 *betas* (not RCs, mind you, betas) have been stable, I doubt you'd be saying much the same thing.
First off, I disagree with your statement that programming is "not a set of building blocks"; writing good code is exactly that (presuming you don't have a severe case of NIH syndrome). Very few projects exist that can't take advantage of some preexisting framework or adopt preexisting code.
At work, I'm on the development team for a large application. We follow best practices -- have frequent design and code reviews, follow the java coding standards as law, make use of design patterns when applicable, and send things back to the drawing board (or at least back for reimplementation) that aren't readable and well-documented. We have an automated test suite, and checking in code that doesn't pass the tests (or checking in new code without tests) brings the wrath of our lead architect, baseball bat in tow. When we finish some of the automation work that's slated, the revision control system will reject code outright that doesn't meet the formatting standards or pass the automated tests, meaning such code will never be checked in at all.
Even on my personal projects, I follow good practices. When writing C, I compile my code with -Wall and run it through valgrind before release. If the design is starting to look cluttered (and the source I'm working on right now *is* getting to look that way), I refactor it before extending it too far. I don't release code to the public if I wouldn't be willing to staple it to the back of my resume.
What I'm saying is that writing good code isn't some kind of magic that needs to come down from a guru on the hill -- yes, coming up with a particularly clever or useful algorithm *does* require intuition, but at least 80% of being a good programmer is a matter not of intuition but of being methodical and taking the time to Do It Right (ie. writing the test cases up front rather than pushing them off, cleaning the lint out of your code rather than just letting it slide as soon as it runs, etc).
Last time I checked, evas was running on systems from x86 linux to win32 to Shaps' Zaurus to Qtopia to win32 ce to directfb. And a MacOS port is on the way.
When was this? I already said that the last time I looked at the code (which was at the time unportable shit) was a few years ago; I can believe that there's been improvement since.
Anyhow, though, unportable shit C is hardly something specific to window managers. If you want me to show you someone who does it better, I'll gladly do that -- but it won't be from a WM; I only rarely dabble in window manager code.
I mean unportable as in making assumptions about data types which are only valid on the architecture the developer is currently using. I mean ugly as in failing to initialize all his data. Even the very latest build of Evolution out of Debian unstable isn't even capable of running under valgrind, and a friend of mine -- one of the MIPS kernel folks and an *extremely* skilled hacker -- who was at one point working on a portable version of E simply threw up his hands in disgust.
So no, I'm not talking about aesthetics.
That said, I disagree that writing cluttered code is at all analogous to having a cluttered room. Efficiency, in the case of code, isn't just how quickly someone can get a first copy written, and it's not just about how fast that copy runs on the developer's box. Code that's blindingly fast on one particular configuration but won't run at all on a different machine (or which loses its performance edge when moved too far) is far worse than code written with attention to algorithmic optimizations, or -- even better -- code which is written with cleanliness and maintainability in mind (to allow for simpler refactoring later, be it for performance or features -- not to mention the far greater advantage of straightforward debugging).
Let me propose an alternate analogy: Cluttered code is akin to poorly-written English -- think of an ill-structured essay or book, full of not only spelling and grammatical errors but logical fallacies to boot. While a cluttered room or desk might be excusable as personal style -- as you put such down to -- cluttered English or cluttered code are both symptomatic of poor thought processes going into their making.
So if you've got the raw partition patches applied, and are letting Oracle provide its own elevator code, you should have similar performance to OS-scheduled async I/O (presuming Oracle's implementation is comparable to the kernel's), *and* make the Oracle I-don't-trust-the-OS-elevator folks happy wrt being confident that writes they think happened really, genuinely happening...
...Rasterman is supposed to be some sort of expert in producing nice fast graphics on X so I'd say this is unlikely.
I'm not so sure of that. Rasterman may have been the first person to write a window manager with quite that much eye candy -- but god, man, have you seen his code?
I can't speak for anything he's written within the last 18 months or so (maybe it's been longer now?), but last time I looked at his C it was ugly, unportable sh*t.
That said, I'll be curious to see what the XRender folks have to say re these benchmarks.
You got that backwards -- ES is for 1 and 2-CPU systems, AS for larger boxen. (And yes, I just checked their web site to make sure *I* wasn't making the mistake).
I'm running RH Advanced Server for a few Oracle instances at work and am not quite so impressed (not *unimpressed*, exactly, just not exactly overwhelmed... the lack of modern volume management support, in particular, is disappointing; and there are few features I've seen to it that strike me as particularly unique.
I'm curious -- what in particular about Advanced Server do you find so impressive?
But the question isn't just if it looks like "redhat linux apache package upgrade" -- the question is if it looks like useful information about "redhat linux apache package upgrade". If the usefulness algorithm can be tuned to the point where data has to genuinely look useful (appears to be not random words but actual (semi?) grammatical sentences, consistant in word usage with other pages on similar topics which are frequently linked to, coming up clean for hostile javascript, perhaps passing a heuristic or two tuned to detect the more naiive methods of cheating the above, whatever -- then it's good enough that the easiest way to "cheat" it is to put up the information the user's really looking for, and when you get to that point, you've won, no?
Of course, what might be really fun (from an "evil" sort of perspective) is to try to see if you can come up with a genetic algorithm or such for generating pages that rank high within thte system... but then, that can be used in reverse: it's pretty damned hard to, even given a full copy of the current net status, reverse-engineer a (sufficiently deep) neural network to decide on what it's making its decisions; a search engine using a neural network for page weighting (just general "usefulness" score, not necessarily with knowledge of the keywords in question) can be quite hard to cheat -- particularly if it's being taught as an ongoing process using input from the pages of effective cheaters.
My general point stands, though: Humans can identify "useful" pages. Why not try to teach a search engine (through AI techniques, fancy heuristics, a combination of the same, whatever) to do just that same thing? That goal achieved, the only way to "cheat" the system is to create a genuinely useful page -- and at that point you haven't cheated at all.
Slashdot Mirror
Simply put: I don't care if burglars or rapists -- or even those who knowingly harm others' property -- are people or not; their actions threaten the safety, wellbeing and personal freedoms of others. These people are most certainly *not* part of the "civilized society" of which you speak, and I see no need to place their lives as more important than the ability of those whom they would victimize to defend themselves.
One major vote fraud technique was "chain voting," where a wily precinct captain would obtain a blank punch card, often by securing an absentee ballot, and punch in the "right" votes. He would then give the prepunched card to a voter -- sometimes solicited off the street with a few bucks or a bottle of cheap wine -- have him go in to vote, drop the prepunched card in the box on the way out and hand the precinct captain another unpunched card. The "chain" could go on all day, as long as cooperating voters could be found and friendly election judges didn't examine things too closely.
*ponder*...
If the box the punched cards are dropped into is specific to the machine (such that the machine can have an optical scanner to look for a barcode on the cards inserted to the box), that's fixable by detecting when cards created during one voting session are used in another.
Of course, this means that we're trusting the machine (bad bad bad!) and introduces potential for false-positive detection scenarios. Even detecting such fraud without taking action on it is useful, however, as it permits a threat of legal followup on any such fraud -- and thus decreases the probability of it occuring -- even if no suspect ballots are actually discarded.
By the way, one issue: Banking and voting are utterly dissimilar, because banking doesn't have the same anonymity requirements. The bank can record who it was that sat at the ATM and punched in a request for a given transaction, and consequently can maintain a verifiable audit trail; the voting machine can't. This makes their security constraints entirely dissimilar.
Heh.
While Linux itself isn't necessarily tremendously innovative, a lot of the stuff being built on top of it is quite so.
Look at LUFS's sshfs module for an example. Yes, userspace filesystems are old hat to anyone who'se worked with a *real* microkernel OS (no, NT doesn't count) -- but allowing unpriveleged users to mount other machines' filesystems with nothing more than ssh access to the remote box is indeed pretty damn innovative.
Another little tool (not necessarily written *just* for Linux) that strikes me as innovative in the extreme: slirp. (If you don't know what it is, go look it up).
Another innovative linux-based project: User-mode linux. (If you're coming from elsewhere, I'll give a rough synopsis: UML makes it very easy to set up fully isolated sandboxes and virtual servers sharing preexisting hardware; permits "kernel debugging" to be done with regular userspace debugging tools; and has far better security and isolation guarantees than most of the convential virtual server mechanisms. I've additionally used it for creating virtual sandboxed networks when trying to reverse-engineer or observe behaviour of hostile code).
These are just things coming off the top of my head. Generally speaking, though: I won't necessarily claim that Linux *itself* is innovative -- but there are a whole lot of people doing innovative things on *top* of Linux.
Software and books are both protected by the same basic copyright laws. Software is frequently *also* protected by a license -- but that license has to be enforcable in and of itself to have any effect. The basic legal protection for software, like books, is copyright; and unless a EULA, in and of itself, meets all the requirements for an enforcable contract (including granting the user consideration -- giving them some right or privilege they didn't have before).
Here's a question for you: I go over to Bob's Software House. I pay Bob $30 for a copy of a program he wrote. There's no license agreement, before or after purchase. What did I just buy?
Answer: I bought a piece of software. Note that the word is "bought" -- not "licensed"; I didn't put down my $30 and sign a licensing agreement, but rather a purchasing agreement. There's substantial legal precedent on point that any activity having the form of a sale is, in fact, a sale itself. Anything else is as silly as claiming that a car dealership can claim that, in fact, you're really just leasing the car you just paid for.
What can I do with it? Use it in any way that doesn't violate copyright. I can't distribute copies or make derivative works -- but for my $30 I can run the software on my computer or make a model aircraft out of it.
Now, let's say I already bought this software, our purchase is concluded, then Bob comes over to my house with a contract he wants me to sign that restricts what I can do with the product I purchased from him beyond the limitations of copyright law. Keep in mind that this contract was not a condition of purchase, and that I already own the copy he sold me.
Two questions are raised:
- Do I have to sign?
- Is the contract even valid, if I do sign?
The answer to the first contract is an obvious no -- I'm under no obligation to sign; I already purchased the software, it is my property and I have the ability to take any action with it which is not prohibited by law.
The answer to the second question is a bit more questionable. A valid contract needs to provide, among other things consideration -- both parties must benefit. If this "contract" only restricts the set of things I can do without providing me with some benefit or placing Bob under some obligation, even if I sign it is void and unenforcable.
BTW: The only restrictions against modifying software you bought (barring a valid contract in place that changes this bargain) are the restrictions against preparation of derivative works -- the exact same law that applies to books. There *are* some recent laws on point regarding reverse engineering, yes -- but those protect it (for purposes of interoperability engineering, for instance) as well as making it illegal under certain circumstances.
Also: What I said above doesn't apply to every state in the Union -- but it applies to most of them. I'm not a lawyer (and indeed, when I was taking contract law, my professor disagreed with me on some of what I'm saying here -- but IP wasn't his field, and there are more than a few real lawyers who do agree with me on those disputed points).
Finally: If you respond to this post, please include your operating legal theory on precicely what rights one has after purchasing the software from Bob's without a license.
Eh? You don't need a license to use software any more than you need a license to read a book. You need a license to reproduce a book (or software), or for the other things limited by copyright (public performance or display, preparation of derivative works, etc)... but *usage* isn't part of that set.
Granted, the argument has been made that "using" software necessarily involves copying it -- but IIRC, some recent laws have clarified that argument out of existance.
I am soon expecting virus writers to plan for the inevitable clean fixes from Symantec and such and, using predictive behavior, ensure that a user can't clean his or her system.
Nothing new about that. Remember the viruses that would encrypt a user's files -- such that after the virus was cleaned, all the files it had touched became inaccessible?
Those were quite popular for a while.
As for Red Hat (formerly) having unnecessary services exposed out-of-the-box -- yup, that's a vendor problem. You'll notice I didn't say anything about the "M" word in my case, but referred to "the vendor" in general.
I'm responsible for the security of the deployment configuration of my company's product, so the words I spoke up there apply to me, as much as anyone else. If I ship something that exposes anything but the most absolutely critical services, I'm to blame. If the user prevents the automatic updates from functioning (because in this product, its update -- and offsite backup -- facility is *enabled* by default), they're to blame. I wasn't bashing Microsoft -- I was stating my beliefs regarding the line between user responsibility and vendor responsibility in general.
And by the way, I wonder as to whether you've ever been in a case where you're locked in to a vendor that suddenly decides to charge you $30K for the next version -- don't buy it, no updates (or support renewals) for you -- which can be more than just a minor annoyance if (say) the huge chunk of in-house software you run your business off of was written around the thing. (Not that I'd have been in a situation like that myself once. Nope, not me. *cough*).
Vendor lock-in sucks, and in a very, very big way -- especially if you don't have the groundwork in place to be able to switch. Even just being able to say that you're capable of moving to a competitor means, at a minimum, far better negotiating terms. Likewise, being fluent with a number of vendors' products comes in handy when you're looking into work and are able to say "yes, I can do that" -- or for the better understanding that such a broader skillset provides.
And while I'm rambling, one last thing: I'm not really fond of Red Hat, but I'm pretty damn sure that their installers at least *used* to support an "upgrade" option that would Do The Right Thing -- and this was around Red Hat 5 and 6.x, so I'd be pretty damn suprised if they didn't still have that functionality today.
It'd be ideal if everyone could drop everything and IT could tell everyone to reboot all systems for a patch for a bug that needs to be deployed, but that just ain't generally the case.
Needing to reboot the whole bloody system to apply any but the most core (ie. tcp stack) security patches is pretty damned broken, too.
There're two issues:
1. There's this bug users didn't patch for
2. The system's default configuration made almost everyone vulnerable being attacked via the bug, even if the user isn't actually making use of the buggy service.
On item [1], yes, there's a really strong argument that it's the user's fault. On item [2], though, it's pretty damn clearly the vendor's negligence.
And they only started doing this under pressure from people who figured out what was going on.
Really, now? And I suppose they only stopped carrying graphical ads when folks complained, right? (Hint: Google's advertising was clearly deliniated from Day 1 -- I've been using it since before they had ads at all, and have no clue whatsoever wtf you're talking about).
Not all companies are soulless -- they just look that way when you're wearing your cynic-colored glasses. I've been at a few engineering-driven companies (one of which, sadly, *stopped* being engineering-driven partway through my tenure) and there really are places where decisions are made based on making a product that we (the engineers making the thing) would personally want to buy, and treating our customers the way we expect to be treated ourselves.
Of course, some of the $@#%^ marketing and strategic-management slimeballs *do* have a tendency to come in and mess all that up in the effort to make a quick buck... but they're not everywhere. "All" companies aren't soulless -- unless you insist on looking at them that way.
It's *waaaay* worse than that for doctors. I work for a medical software startup, and two of the head honchos are MDs (one an ER surgeon, the other a general practitioner). Not only are their student loans frequently a whole lot bigger than that, but malpractice insurance starts on the area of $70-150k/year for a doctor with a perfectly clean record (more for neurosurgeons and other folks in sensitive specialties). They've mentioned patients dying in smaller communities around here because there was no neurosurgeon available anywhere they could fly them to in time because nobody can afford to be in the business -- the malpractice rates are just too high (and *that* is largely the case because of the huuuge damages that often get awarded when a MD screws up).
So yes, it's a mess, and people really *are* dying because of it. *sigh*.
I'm in Texas, though. I don't know what it's like right now in California.
Proper disaster planning involves both minimization of the likelihood of failures *and* minimization of the impact of the failures that occur anyways. Having either without the other just ain't good enough -- one way you have frequent failures (but prevent really massive problems from resulting) and the other way the rare failures that get by anyhow are downright disasterous.
"setting up a strawman" -- creating a false version of your opponent's argument that you could knock down easily.
.net after it and related projects (Mono) have had some time to mature... but in mentioning those I've wandered *very* far off topic indeed.
My employer is a stealth-mode startup; I can't talk about what we do. Unlike my last job (at MontaVista Software), our product isn't open source -- but several of our components and tools are, and we've contributed some patches back.
As for reusability, *shrug* -- it depends. I've found stuff like DB access layers (and frameworks -- see Struts for a good example) to really be quite reusable when done correctly. For that matter, though, my current personal project was able to save hundreds if not thousands of lines by reusing the parser and related framework from Checkstyle (which is extended to keep token location information accessible from the AST). Of course, that wouldn't be possible if Checkstyle weren't designed so well.
On past projects, likewise, I've been able to really, truly and succesfully put multiple frontends to a single backend written without knowledge of any of them. This last bit is key -- if I'd been writing the backend while writing a frontend to drive it (other than the test harness), my backend probably really *would* have ended up tied to that frontend -- or at least needing changes to work elsewhere.
BTW, I'd argue that there do exist methods for creating solid-as-a-bridge software. Look at Knuth and his creation of mathematical proofs for the algorithms he uses -- and look at just how solid TeX has been in the years since he wrote it.
As for never seeing reusability work well beyond STL, I'd strongly advise that, should the opportunity become available, you try something other than C++. Personally I favor Python -- its introspection layer permits functionality that would just be unthinkable or could require 10-20x more code elsewhere (for instance, a paint program I wrote back in school in Jython implemented the following functionality in less characters than I'm taking to describe it: "look at the static members of java.awt.Color; find all which are instances of java.awt.Color and add them to a list of colors available to the user and to a mapping of known colors to the colors' names"). I'd call this reusability, after a fashon -- I'm reusing the list of colors in java.awt.Color, in a manner the creators of this class never expected. Java, for all its warts (of which it has fewer now than before -- as of 1.4 it has an equivalent to the select() call, and 1.5 will have some substantial language-level improvements) has a very large amount of reusable 3rd-party code available, making it frequently possible to avoid any more work than necessary writing things other than core business logic. Take a look at the Jakarta suite of libraries, frameworks and tools (particularly Struts and Torque) for an example of the goodies available to folks looking for reusable components for larger-scale projects.
I'm also hopeful for
Ahh.
.0 release (unless, of course, you're Linus... *sigh*).
.0 designation. A few scenarios, therefore, present themselves:
Dunno, though -- I'm (strongly) guessing that these folks are suffering from configuration issues more than anything else. A release candidate, after all, is something which actually *could* become the
As a result, a RC generally won't have known issues large enough to prevent release -- because if it had such known issues, it wouldn't be eligable for
1. The folks complaining about Samba 3.0 here had severe configuration issues (failure to RTFM).
2. The folks complaining about Samba 3.0 here are basing their complaints from a release *prior* to the release candidate.
3. The folks complaining about Samba 3.0 here are hitting bugs obscure enough that the maintainers didn't know about them when deciding to make this a RC release.
4. The folks complaining about Samba 3.0 here are hitting bugs minor enough that the maintainers are willing to release with them in place.
No doubt the truth is a mix of these -- but I'm guessing that a strong majority of issues encountered will be of the former two varieties.
Depends on the team. What some people release as "just an RC" others release as final and still others hold back as alpha or beta. Saying "release candidates are always garbage" takes nothing into account wrt the release management style of the programming team in question.
Now, if you had something to say about the quality of the Samba team's RC releases in particular, that'd be worthwhile -- but given how long the Samba 3 *betas* (not RCs, mind you, betas) have been stable, I doubt you'd be saying much the same thing.
You're setting me up a strawman.
First off, I disagree with your statement that programming is "not a set of building blocks"; writing good code is exactly that (presuming you don't have a severe case of NIH syndrome). Very few projects exist that can't take advantage of some preexisting framework or adopt preexisting code.
At work, I'm on the development team for a large application. We follow best practices -- have frequent design and code reviews, follow the java coding standards as law, make use of design patterns when applicable, and send things back to the drawing board (or at least back for reimplementation) that aren't readable and well-documented. We have an automated test suite, and checking in code that doesn't pass the tests (or checking in new code without tests) brings the wrath of our lead architect, baseball bat in tow. When we finish some of the automation work that's slated, the revision control system will reject code outright that doesn't meet the formatting standards or pass the automated tests, meaning such code will never be checked in at all.
Even on my personal projects, I follow good practices. When writing C, I compile my code with -Wall and run it through valgrind before release. If the design is starting to look cluttered (and the source I'm working on right now *is* getting to look that way), I refactor it before extending it too far. I don't release code to the public if I wouldn't be willing to staple it to the back of my resume.
What I'm saying is that writing good code isn't some kind of magic that needs to come down from a guru on the hill -- yes, coming up with a particularly clever or useful algorithm *does* require intuition, but at least 80% of being a good programmer is a matter not of intuition but of being methodical and taking the time to Do It Right (ie. writing the test cases up front rather than pushing them off, cleaning the lint out of your code rather than just letting it slide as soon as it runs, etc).
Enlightenment. That was just a brief brain/fingers disconnect. Oops.
Last time I checked, evas was running on systems from x86 linux to win32 to Shaps' Zaurus to Qtopia to win32 ce to directfb. And a MacOS port is on the way.
When was this? I already said that the last time I looked at the code (which was at the time unportable shit) was a few years ago; I can believe that there's been improvement since.
Anyhow, though, unportable shit C is hardly something specific to window managers. If you want me to show you someone who does it better, I'll gladly do that -- but it won't be from a WM; I only rarely dabble in window manager code.
As for my window manager, I use ion.
I mean unportable as in making assumptions about data types which are only valid on the architecture the developer is currently using. I mean ugly as in failing to initialize all his data. Even the very latest build of Evolution out of Debian unstable isn't even capable of running under valgrind, and a friend of mine -- one of the MIPS kernel folks and an *extremely* skilled hacker -- who was at one point working on a portable version of E simply threw up his hands in disgust.
So no, I'm not talking about aesthetics.
That said, I disagree that writing cluttered code is at all analogous to having a cluttered room. Efficiency, in the case of code, isn't just how quickly someone can get a first copy written, and it's not just about how fast that copy runs on the developer's box. Code that's blindingly fast on one particular configuration but won't run at all on a different machine (or which loses its performance edge when moved too far) is far worse than code written with attention to algorithmic optimizations, or -- even better -- code which is written with cleanliness and maintainability in mind (to allow for simpler refactoring later, be it for performance or features -- not to mention the far greater advantage of straightforward debugging).
Let me propose an alternate analogy: Cluttered code is akin to poorly-written English -- think of an ill-structured essay or book, full of not only spelling and grammatical errors but logical fallacies to boot. While a cluttered room or desk might be excusable as personal style -- as you put such down to -- cluttered English or cluttered code are both symptomatic of poor thought processes going into their making.
Ahhh.
So if you've got the raw partition patches applied, and are letting Oracle provide its own elevator code, you should have similar performance to OS-scheduled async I/O (presuming Oracle's implementation is comparable to the kernel's), *and* make the Oracle I-don't-trust-the-OS-elevator folks happy wrt being confident that writes they think happened really, genuinely happening...
Or am I missing something here?
...Rasterman is supposed to be some sort of expert in producing nice fast graphics on X so I'd say this is unlikely.
I'm not so sure of that. Rasterman may have been the first person to write a window manager with quite that much eye candy -- but god, man, have you seen his code?
I can't speak for anything he's written within the last 18 months or so (maybe it's been longer now?), but last time I looked at his C it was ugly, unportable sh*t.
That said, I'll be curious to see what the XRender folks have to say re these benchmarks.
You got that backwards -- ES is for 1 and 2-CPU systems, AS for larger boxen. (And yes, I just checked their web site to make sure *I* wasn't making the mistake).
Yes, I think it's intuitively backwards too.
I'm running RH Advanced Server for a few Oracle instances at work and am not quite so impressed (not *unimpressed*, exactly, just not exactly overwhelmed... the lack of modern volume management support, in particular, is disappointing; and there are few features I've seen to it that strike me as particularly unique.
I'm curious -- what in particular about Advanced Server do you find so impressive?
...but Oracle won't support it.
That's not to say it won't work, or that they won't support non-OS-related database issues... but that still may make it unacceptable.
But the question isn't just if it looks like "redhat linux apache package upgrade" -- the question is if it looks like useful information about "redhat linux apache package upgrade". If the usefulness algorithm can be tuned to the point where data has to genuinely look useful (appears to be not random words but actual (semi?) grammatical sentences, consistant in word usage with other pages on similar topics which are frequently linked to, coming up clean for hostile javascript, perhaps passing a heuristic or two tuned to detect the more naiive methods of cheating the above, whatever -- then it's good enough that the easiest way to "cheat" it is to put up the information the user's really looking for, and when you get to that point, you've won, no?
Of course, what might be really fun (from an "evil" sort of perspective) is to try to see if you can come up with a genetic algorithm or such for generating pages that rank high within thte system... but then, that can be used in reverse: it's pretty damned hard to, even given a full copy of the current net status, reverse-engineer a (sufficiently deep) neural network to decide on what it's making its decisions; a search engine using a neural network for page weighting (just general "usefulness" score, not necessarily with knowledge of the keywords in question) can be quite hard to cheat -- particularly if it's being taught as an ongoing process using input from the pages of effective cheaters.
My general point stands, though: Humans can identify "useful" pages. Why not try to teach a search engine (through AI techniques, fancy heuristics, a combination of the same, whatever) to do just that same thing? That goal achieved, the only way to "cheat" the system is to create a genuinely useful page -- and at that point you haven't cheated at all.