My first thought was that they might have done something slightly different from a familiar old symlink by applying "copy on write" semantics. While I couldn't find anything in the article that unambiguously states whether they're doing this, I did find:
>The first piece searches for duplicate files, computes a signature for each file and stores these signatures in a database. It then compares the signatures in the database and merges duplicate files.
This is actually kinda nice. It's going out and looking for copies, instead of relying on you to create the links explicitly. In order for this to be truly transparent you'd have to use COW, of course. There's also a concern about how much CPU time and bus bandwidth will get used finding and tracking these duplicates. Lastly, let's not forget that it would be trivial to create a daemon to do the same thing on any UNIX.
In short, it's an interesting idea, but perhaps still a bad one. In any case, I don't think it's "just a reinvention of the symlink" even though MS has tried to take credit for a lot of rather ancient computing ideas.
>SCSI is busmaster-based: only one drive can use the bus at a time.
Lest anyone misunderstand, this only means that one device (including initiators) can be _on the bus_ at once. It does not preclude there being more than one request outstanding to the same or multiple devices at one time, waiting for disks to spin etc.
Aye, there's the rub. This may seem like "common knowledge" to you or to the many other web-wankers out there, but in fact neither the typical user nor most kinds of computer specialists outside of your narrow little specialty know (or should know, or should have to care) what a QUERY_STRING is. In fact, I'll bet a large number of web-wankers, unschooled as you lot tend to be before you start proclaiming yourselves gurus, don't know what a QUERY_STRING is either because you never see one behind the layers of cruft in a web "authoring" tool someone with marginally more talent than you provided.
And that is more than "remotely alarming". The real issue is that idiots can and do create web pages, so we need something that's safe to use even when those idiots are involved.
Lest anyone think that I'm saying the open-sourcers have "gotten it right" let me set the record straight. Closed source has its characteristic problems, some (but not all of which) can be addressed by looking to the open-source model. Open source also has its characteristic problems, which I'd say come down to lack of discipline.
The first symptom of this is that open source tends to be all about programming, without anywhere near enough attention to design, testing, documenting, etc. As much as we bash MS for using their users as guinea pigs, open source tends to rely on users even more heavily in lieu of real testing. Yes, I know, at least open-source users have volunteered to be guinea pigs and haven't paid for the honor, but I think that's an inadequate excuse for developers shirking an important part of their role.
The second symptom is lack of a means to control the jerks. I think the majority of open source folks favor cooperation, but a substantial number are more competitive than cooperative. They want to be top dog, or they don't want to be in the pack. When this attitude is recognized, they can be removed from a project by those that remain, but that recognition is often preceded by a lengthy period during which they're allowed to be obstinate and disruptive and generally counterproductive. When dealing with volunteers, it's harder to get people to shut up and do their assigned task, because there's no repercussions to them. They won't suffer for years from bad reviews or bad references, the fear of which is at some level a powerful motivating force in the commercial world not to be too much of a jerk.
As I said at the top, each approach has its problems. The benefits of open source may well outweigh the problems I've described, but it's not a panacea.
>However, the people who are writing code for software should not be allowed to design that same software.
I strongly disagree, for the same reasons others have. They've done a fine job explaining the problem(s) already, so I won't duplicate their efforts. Instead, I'd like to suggest what I think is a better solution than what you propose.
Here are a couple of ideas that should warm the hearts of/. types: openness and shared ownership. Yes, even if the product is proprietary, these things work wonders. The problem you're worried about occurs not because the same person does both design and implementation, but because they're allowed to do either in a bubble, isolated from other opinions and views and influences. If both the design and the implementation are laid out for other people to see and comment on, and if those other people feel that they "own" any potential bugs in the code as much as the primary author, those potential bugs will be prevented from becoming real bugs. There's nothing worse than a programmer who never lets on what they're up to, and nothing better than a programmer who realizes that leading other people through the process is even better than excluding them.
>If I remember correctly..companies get rank newbies to write drivers.
Absolute bullshit. Writing kernel-mode software - which includes true drivers plus many other driver-like entities such as filesystems - is much harder than writing user-mode fluff, for several reasons:
You have to understand not only how to write software, but also how one or more pieces of hardware work, in detail.
You have to deal with OS interfaces that are typically more complex and less friendly than those at user level.
You can never punt on concurrency or reentrancy issues like you often can at user level; very little kernel code has the luxury of assuming that only one thing is happening at a time.
Debugger support for kernel-mode code is a decade or more behind that for user-mode code. Between this, the last item, and the fact that everything in a driver tends to be time-sensitive, this means you can't just step through sloppy code to see what it's really doing - you have to know absolutely it will work as you intended. Interestingly, this is one area where NT absolutely shines in comparison to any UNIX flavor.
Performance is pretty much always an issue for drivers, and not just your own performance but also the effect that your choices have on overall system performance. For example, keeping lots of recalculable values around will waste physical memory, so even if it allows greater internal efficiency it may be unacceptable from a systemwide viewpoint.
You're invariably restricted in your choice of languages. It's C and occasionally a little assembler. C++ is generally not supported for kernel-mode development (except on NT). Sometimes you can make it work by basically writing your own C++ runtime library from "new" on up, but it's usually more work and more headaches (e.g. constructor invocation might not happen "right") than it's worth. You can just plain forget about Java or any scripting language, and while you're at it you can forget about those class libraries you love so much.
If you do manage to screw up, the whole system crashes. At the very least, this means you have to wait for a reboot; sometimes it means data is corrupted or even that hardware got fried. No more "oh well, just restart the program" three seconds later.
It's really hard to hire experienced kernel-mode developers, and when we get desperate enough to hire people without kernel experience because "they seem smart and we hope they can learn" we find two things:
About half just never get used to the more demanding environment, and go back to user-mode work.
Those who do make it take six months or more to become reasonably productive.
We're not talking about fresh-outs here, either. People with five or six years of experience - but none of it in kernel mode - are only marginally better than kids in either of the above regards (and they cost a lot more).
Yes, people who write drivers often leave for other jobs, dumping their code on other people for maintenance. That's not because they're 18 year olds who don't have a clue, though. Au contraire; it's because driver developers always have a wealth of opportunities to choose from, and who wants to maintain old code instead of writing something new?
IANAL, but I've been involved in legal matters and talked to lawyers a bit. There's a very difficult distinction involved here that I'll try to clarify a little. The law doesn't recognize actual intent or state of mind, rightly holding these things to be unknowable in any specific instance. However, the law does recognize that the maker of a tool or provider of a service "should have known" how that tool/service might be used. It's very similar to the standard of diligence applied in many other areas. For example, libel/slander cases often hinge not on whether the accused did know that a statement was false, but on whether they should have known and failed to exercise due diligence in checking their facts. Ignorance is not necessarily a permissible excuse under the law, especially when the claim of ignorance is either facile or tantamount to professional malpractice.
With respect to software, I think the application of this principle is pretty obvious. The person who uses a software tool illegally always bears some responsibility; the question is whether the software author is responsible as well as - not instead of - the user. This can pretty much only be true when the maker of software "should have known" that their software would be used in such a manner, that such use could have been prevented without undue burden or compromise of other functionality, and that the author nonetheless did nothing to prevent it. The phrase "should have known" is of course vague, but I think people who work in a field generally have a pretty strong consensus on what's common knowledge and what's not. What one person in the field should have known, is what the majority of practitioners do know or could figure out in a jiffy.
This definition obviously does not indict word processors or other common types of software. It's not even clear that it indicts something like SATAN, which the author deliberately tried to present to system administrators and such as a way to improve security. I think the line gets crossed with something like Back Orifice, which was very obviously pushed primarily as a way to hack systems; any claims about it being a remote administration tool are obviously accompanied by a smirk and a wink, which would only piss off judges and juries. Even if the tool's primary purpose was legal and positive, it's pretty bleeding obvious that it can also be used illegally and negatively. Some announcement of its presence on a system would discourage the latter use while in no way interfering with the first, and the absence of such announcement could readily be construed as an indication of the author's lack of professional diligence (remember, we can't impute malice because that comes down to a matter of concrete intent).
>the whole point of the NetApps is to be faster than local storage. and they are, as long as your network is fast enough.
I think network-attached storage is a fine idea and the "right solution" for many things, but I just have to add a rebuttal here anyway.
Network-attached storage is faster than local storage if your network (including the protocol stack) is fast enough and your local-storage subsystem (including its own separate protocol stack) is slow enough. That's a totally useless claim. It's like saying that a train is faster than a car, leaving out the part about the train being an unloaded bullet-train engine on an empty track and the car being a Yugo stuck in New York traffic.
In actual fact, the raw bandwidth of modern storage interconnects (e.g. UW SCSI, FC) is higher than that of most network interconnects (e.g. 100baseT) for which the adapter cost is similar. In addition, the protocols used for storage (e.g. SCSI, the various layers of FC) are more suited toward that task - duh - than are the protocols used for networking (e.g. TCP/IP). There is no reason in hell that it should be faster to use network interconnects and protocols to access your storage than to use storage-specific interconnects and protocols.
Why might it appear that network-attached storage performs better? I can think of at least three reasons right off the top of my head:
Many computers are "unbalanced". They are misdesigned or misconfigured so that they have a lack of direct-to-storage capability coupled with an excess of network capability. This may actually make NAS the correct solution for that environment but is irrelevant when considering the overall merits of the two approaches.
Network-attached storage devices often benefit by having much more cache than direct-attached storage devices. If you took that same amount of cache and applied it to the direct-attach devices, the NAS boxes wouldn't look so good.
The caching strategies used for NAS - i.e. thos in NFSv3 - sacrifice consistency for speed, while direct-attach systems are held to a higher consistency standard. Everyone who has tried to use NFS for something where data consistency or up-to-date modification times matter - even something like "make" - has probably cursed NFS already over this. Some NFS vendors make things even worse by failing even to meet the NFS requirements. Sun's own Solaris NFS client, for example, doesn't always flush data when it's supposed to. If you added all the appropriate sync() operations and fixed the NFS implementations so that your NAS solution was really doing the same thing as your direct-attach solution, you might see some different performance comparisons. Note, though, that for many applications the NFS tradeoff and hence the NAS solution is pretty reasonable.
At this point I should disclose my own biases. First, I work for EMC. That's not by choice - the company I was working for got bought out - and I'm often not thrilled about it, but the pay is good. In particular, I don't buy in to all of EMC's arrogant "storage is the center of the universe and the Symmetrix is the ultimate storage device" attitude, and I heartily dislike our own Celerra NAS product even though it blows the doors off NetApp in terms of performance and scalability. Secondly, my professional areas of interest include distributed, cluster, and SAN filesystems, so I of course have some fairly strong opinions on such matters. That said...
I think that once we start seeing true, mature, multi-platform shared-storage filesystems, NAS will start to seem much less appealing. Why pay for NAS when you can just add software to your existing hardware investment and get all the sharing with almost all the performance of local access? Now all we need is a decent implementation of such a filesystem.
>Am I mistaken in thinking that the $0.25/device is merely for the licensing? The cost of implementation is certainly more than that for both formats? Yes, that is just the cost of licensing, and yes, the cost of implementation is more than that for both formats. However, the cost to implement presents an interesting tradeoff.
USB is based on a model of hosts polling devices. This allows for cheaper device implementations, because devices don't need to initiate transactions, but makes the host-side implementation more complex. It's a good fit when you have several dumb devices and the polling latency doesn't matter - mice, keyboards, stuff like that.
1394 is more peer-to-peer, with devices able to initiate transactions independently. This makes device implementations more costly and host implementations less so. It's a good fit when you only have one or a few devices, when the polling latency matters, or when the device is connected to more than one machine.
My point, besides the obvious complementary nature of the two approaches, is that Intel has a much higher market share in motherboard chipsets than in consumer electronics. Of course they're going to push the host-centric solution, because they can bury a lot more profits for themselves in the cost of a motherboard.
>I'd like to see some progression on IEEE-1355.. I dunno offhand what the status of work on 1355 is, but it's a far more exciting technology than either USB or IEEE-1394.
It sounds interesting, but I'm not convinced yet. How many nodes does it support on a simple loop/bus/whatever without added-cost routers/switches. How hot-pluggable is it? Does it support isochronous transfers?
I have the feeling that 1355 may be a truly great thing...for another niche. It may be a mistake to push it as an alternative or replacement for 1394, just as it is/was a mistake to push USB - a perfectly wonderful thing in its own niche - the same way.
How convenient for Intel, that they can hide the USB2 implementation cost in higher chipset prices (hint: more than the $0.25/device Apple et al are charging for 1394). Even if USB2 were technically superior to 1394 - which it's not - I'd be leery of adopting a "standard" controlled by a single manufacturer over one approved by IEEE. That goes double if the manufacturer is Intel.
Maybe VIA or someone will integrate 1394 on their motherboards instead of USB2. That would be great.
>Apple demands one dollar per firewire chip in royalties.
At least it's an honest, up-front charge. The "Intel tax" on USB2 is likely to be much higher, but hidden in things like increased motherboard/chipset prices. I'll gladly pay a buck for the difference between an IEEE standard and yet another Intel pseudo-standard, and I think most educated consumers would as well.
>But in lecture they told us that the OS has two functions (ok more like 1.5 functions): >1). Load and execute a user program >2). Provide an abstraction for the machine's hardware so that a user program can access it.
I think this is an argument for defining "OS" and "kernel" separately. The syscall interface provided by a kernel isn't really an abstraction of the hardware any more - not for a couple of decades. It's just an API, really, and not usefully different from other APIs; the fact that this particular API involves traps into a privileged processor mode really doesn't count for much. Do most people even know what's different about, say, open() and fopen()?
I'm not disagreeing with you, just trying use what you said as a jumping-off point for my own agenda du jour.;-)
Opinions are like...well, you've all heard that one.;-) Here's mine.
Several posters have already tried to make a distinction between "kernel" and "OS", and I think this distinction is becoming more and more accepted in the computing community. In five years it seems likely that nobody but dinosaurs will consider the two terms interchangeable.
To me, an OS is the set of software that makes hardware suitable for its intended application(s). This makes the definition very relative to what the hardware's intended applications actually are. Some examples:
For an embedded hard-realtime control system, there might be little or no OS to speak of. The hardware is already adequate for its "application" which consists of hardware-specific monitoring and control code.
For a "softer" kind of embedded system such as a touch-screen ATM, the OS consists of some hardware abstraction and some tools to write a very limited class of applications.
For a general-purpose workstation or PC, the OS has to provide a very high level of abstraction and functionality to support a very broad class of applications.
Since nobody here ever seems to care about or even recognize the existence of computers that aren't on the desktop, I'll expand a little on that last example. I think a desktop OS can and should include things like libraries for GUI and sophisticated IPC functionality, because those are now elements of the dominant application paradigm for that class of devices. Some might think that something like a JVM is also included, but I don't agree...not for a couple more years. Editors, compilers, etc. are definitely _not_ part of the OS in my opinion; they are the applications that define what an OS for that platform is or should be. Think of it as a tree formed by application dependencies on libraries or services, library dependencies on kernels or other libraries, etc., with the hardware as the root. That part of the tree extending from the root and required by the majority of leaves is what I'd call the OS.
Defining kernel is another problem. The standard definition is "code that runs in a privileged processor mode". This definition has a few weaknesses - it would make everything in our hard-realtime example "part of the kernel" and it doesn't distinguish between loadable and permanent code - but overall it's pretty good. Perhaps a slightly more accurate though more cumbersome definition would be "the privileged monolithic code which maps between the actual hardware and a set of well-defined abstractions of that hardware [e.g. virtual memory and device driver interfaces]".
Several people have pointed out that patents like these not only won't stand up in court, but that they're not even intended to. I'd like to expand on that a little.
I remember reading somewhere that a patent-office official had publicly admitted that they couldn't keep up with the flood of applications and were as a matter of policy allowing dubious patents through in the hope that the courts would sort things out. Whether the admission was real or just a figment of my imagination, this is clearly what the patent office is doing.
Patents are supposed to be (a) innovative, and (b) non-obvious, among other criteria. This patent is obviously neither, and there are enough other companies with enough legal muscle to ensure that it's never enforced, so I don't think it's much to worry about. The danger comes when a patent is granted on something obscure and the only people who care are little guys who don't have the resources to fight it successfully in court by themselves.
This brings me to my other point: patent fights. It's very common nowadays to respond to an accusation of infringement by pulling out a few of your own. "Oh yeah? Well, you're infringing our patents X, Y, and Z. Are you sure you want to take this to court?" That is what's really behind a lot of the "preemptive patenting" to which several other posters have referred. One of the tools of the high-tech business is developing a patent portfolio not so those patents can actually be used to club others over the head, but to avoid being clubbed oneself. Companies have been bought just to pad patent portfolios. It's sick, I know. I'm not defending the practice, just reporting it.
Computing has been pretty good for my real life. My first two serious romantic relationships started on M-Net, as did a long-standing friendship which was the critical contact allowing me eventually to leave a dead-end job in Michigan for what turned out to be a fairly rewarding career in Massachusetts. After that move, I met the woman who is now my wife, via alt.personals, and we exchanged email for several months before we met IRL. During a hiatus from that relationship before we got married (don't ask) I had another brief relationship, started this time on LambdaMOO.
Those are my credentials as a veteran of on-line romance. Now, the point I want to make is that the net is just a medium. To me, these relationships I've had aren't "net relationships" any more than using a phone to communicate makes them "phone relationships". They're relationships with people and the medium doesn't really matter.
There are many people who seem to develop an online persona that's different from their RL one. I'm not just talking about the sort of contextualization that causes us to interact differently with our children in the back yard and our boss at a cocktail party; I'm talking about something that's almost clinically recognizable as multiple personalities. These people often fear "crossover" between their real and virtual lives, and resist bringing the two together, because of what people may discover about their own "other self". Does this sound like a formula for long-term success and stability, romantic or otherwise? Obviously not. Most people who are online long enough eventually outgrow this phase and learn that the proper emphasis in "being yourself online" is on "being yourself" rather than "yourself online". People who maintain the separation too much or too long need to figure out what's so wrong with their real lives that they rely on their virtual lives as a refuge. Only then, IMO, can they expect to get anything substantial out of their interactions online.
>We have redundant power supplies, hard drives, and many other pieces of hardware. I am thinking it may be good for developpers, at any rate, to use redundant kernels. >... >Interrupt in service: a few clock cycles
Sorry, but this doesn't work. You'd have to replicate the entire kernel address space including that used by drivers and on behalf of user programs for it to be effective. Many crashes actually result from corruption of some part of kernel memory, so if the two kernels share data they'd both crash at once. In addition, because the in-kernel data structures kept on their behalf might be different (if the two kernels were precisely identical they'd also crash in tandem) the user programs would have to be duplicated too. Now you've halved your memory and CPU resources, plus you're effectively doing a context switch "every few instructions" to go from one kernel to the other. Your performance is going to be totally abysmal.
The solution? Do what fault-tolerant systems already do and replicte the hardware as well. Been there, done that, works OK but gives lousy performance/dollar compared to non-FT alternatives. If you don't want to pay that premium you can go with a clustered highly available system such as the ones I once helped develop. Unlike an FT system, an HA system will allow an interruption when a component fails, but the duration of that interruption will be very short relative to a "vanilla" non-FT non-HA system. Also, in the absence of failures the component nodes of an HA cluster (a well-designed one, anyway) are able to process their own independent workloads instead of sitting around idle or duplicating each other's work.
>Hacking the kernel is supposed to be hard and tracing crashes given minimal information is a big part of the fun and attraction of ``iron man'' programming
That's fine if your goal is to compensate for deficiencies elsewhere in your life by making yourself feel like an "iron man" programmer. If your goal is instead to produce working quality kernel code, you eventually ask yourself "why make an intrinsically difficult task even more difficult by not using the best tools available"?
If self-flagellation or self-denial are good things, might as well go all the way, right? Go build your own computer...from sand and copper ore, using no tools but those you make yourself. Come back when you're done.
>...has to do with how many memory different places in the cache each memory address can reside
That's a very good description. Thank you.
There's also a rule about the relationship between associativity, cache size, and hit ratios. It's quoted in H&P, but I can't quite remember it; can anyone else help out? I'm tempted to say "an N-way associative cache of size X will generally achieve hit ratios similar to a direct-mapped cache of size X/N" but that seems a little too optimistic.
>This isn't baseball, you don't have to worry about things like point-shaving... if companies selling their own derivatives bothers you, don't buy them -- no company in their right mind would "take a dive" to make money off their own derivatives
I'm not sure I agree with this. Companies don't have minds, right or otherwise. Officers of companies have minds, and it's not hard to imagine unscrupulous officers manipulating stock prices in ways that benefit them but not their stockholders. It's not even hard to imagine them getting away with it; corporate officers have gotten away with worse things quite a few times.
This guy's definitely not quite level-headed. I particularly like his suggestions to disallow MS from issuing options (draconian) and to invite him on talk shows (self-promotion). His characterization of MS's practices as "employees prepaying wages" is as inaccurate as the accounting practices he decries, and his characterization of "tax loopholes and corporate welfare" as 36% of income (or any % of income) is disingenuous to say the least. He obviously has an axe to grind and not much regard for accuracy.
On the other hand, he does make some good points:
There really is a problem with how options are accounted for, and MS does take advantage of this "legal lag" more than most.
Selling options on your own stock - especially puts, but also calls - just doesn't seem right and should probably be illegal.
Having to pay a $4M settlement to an internal auditor who was fired and then invoked the whistleblower act seems really fishy to me.
There seems to be a good chance that MS really is cooking the books even more than is generally allowed (which is still way too much IMO). It's certainly not proven, and probably won't be by this author, but there seems to be ample reason to look into the matter more carefully.
>There is general problem with how companies have to account for stock options given to employees.
That was actually one of the author's points.
What's the solution? Forcing companies to account for all granted options as income is really not quite right, because many of those options will in fact never vest. The fairest thing would seem to be a requirement for a "good faith" estimate of what percentage of options will vest, based on industry averages and/or prior experience at that company. That portion would then have to be accounted as income. It's no different really from many other things in a company's financial statements that are actually just estimates.
>'Creative accounting' is used by most major corporations, Billy G didn't invent it.
I do hope you're not implying that we should just not try to enforce any kinds of standards for accounting. That would be a classic example of the "excluded middle" fallacy, so obvious even the average slashdotter could see through it.
Sure, creative accounting has been around for a long time and many companies get away with a certain amount of "creativity" within the limits that we do set. But some companies - Sequoia and KSR come to mind - don't get away with it because their practices have gone beyond creativity into outright fraud. If we are to allow those companies to fail for their dishonesty, why should Microsoft be held to a more lenient standard?
We may not be able to make everyone perfectly honest, but we can prevent or discourage some of the most blatant forms of corporate dishonesty and that's what this article is about.
Slashdot Mirror
My first thought was that they might have done something slightly different from a familiar old symlink by applying "copy on write" semantics. While I couldn't find anything in the article that unambiguously states whether they're doing this, I did find:
>The first piece searches for duplicate files, computes a signature for each file and stores these signatures in a database. It then compares the signatures in the database and merges duplicate files.
This is actually kinda nice. It's going out and looking for copies, instead of relying on you to create the links explicitly. In order for this to be truly transparent you'd have to use COW, of course. There's also a concern about how much CPU time and bus bandwidth will get used finding and tracking these duplicates. Lastly, let's not forget that it would be trivial to create a daemon to do the same thing on any UNIX.
In short, it's an interesting idea, but perhaps still a bad one. In any case, I don't think it's "just a reinvention of the symlink" even though MS has tried to take credit for a lot of rather ancient computing ideas.
>SCSI is busmaster-based: only one drive can use the bus at a time.
Lest anyone misunderstand, this only means that one device (including initiators) can be _on the bus_ at once. It does not preclude there being more than one request outstanding to the same or multiple devices at one time, waiting for disks to spin etc.
>anyone who knows what a QUERY_STRING is
Aye, there's the rub. This may seem like "common knowledge" to you or to the many other web-wankers out there, but in fact neither the typical user nor most kinds of computer specialists outside of your narrow little specialty know (or should know, or should have to care) what a QUERY_STRING is. In fact, I'll bet a large number of web-wankers, unschooled as you lot tend to be before you start proclaiming yourselves gurus, don't know what a QUERY_STRING is either because you never see one behind the layers of cruft in a web "authoring" tool someone with marginally more talent than you provided.
And that is more than "remotely alarming". The real issue is that idiots can and do create web pages, so we need something that's safe to use even when those idiots are involved.
Lest anyone think that I'm saying the open-sourcers have "gotten it right" let me set the record straight. Closed source has its characteristic problems, some (but not all of which) can be addressed by looking to the open-source model. Open source also has its characteristic problems, which I'd say come down to lack of discipline.
The first symptom of this is that open source tends to be all about programming, without anywhere near enough attention to design, testing, documenting, etc. As much as we bash MS for using their users as guinea pigs, open source tends to rely on users even more heavily in lieu of real testing. Yes, I know, at least open-source users have volunteered to be guinea pigs and haven't paid for the honor, but I think that's an inadequate excuse for developers shirking an important part of their role.
The second symptom is lack of a means to control the jerks. I think the majority of open source folks favor cooperation, but a substantial number are more competitive than cooperative. They want to be top dog, or they don't want to be in the pack. When this attitude is recognized, they can be removed from a project by those that remain, but that recognition is often preceded by a lengthy period during which they're allowed to be obstinate and disruptive and generally counterproductive. When dealing with volunteers, it's harder to get people to shut up and do their assigned task, because there's no repercussions to them. They won't suffer for years from bad reviews or bad references, the fear of which is at some level a powerful motivating force in the commercial world not to be too much of a jerk.
As I said at the top, each approach has its problems. The benefits of open source may well outweigh the problems I've described, but it's not a panacea.
>However, the people who are writing code for software should not be allowed to design that same software.
/. types: openness and shared ownership. Yes, even if the product is proprietary, these things work wonders. The problem you're worried about occurs not because the same person does both design and implementation, but because they're allowed to do either in a bubble, isolated from other opinions and views and influences. If both the design and the implementation are laid out for other people to see and comment on, and if those other people feel that they "own" any potential bugs in the code as much as the primary author, those potential bugs will be prevented from becoming real bugs. There's nothing worse than a programmer who never lets on what they're up to, and nothing better than a programmer who realizes that leading other people through the process is even better than excluding them.
I strongly disagree, for the same reasons others have. They've done a fine job explaining the problem(s) already, so I won't duplicate their efforts. Instead, I'd like to suggest what I think is a better solution than what you propose.
Here are a couple of ideas that should warm the hearts of
Absolute bullshit. Writing kernel-mode software - which includes true drivers plus many other driver-like entities such as filesystems - is much harder than writing user-mode fluff, for several reasons:
It's really hard to hire experienced kernel-mode developers, and when we get desperate enough to hire people without kernel experience because "they seem smart and we hope they can learn" we find two things:
We're not talking about fresh-outs here, either. People with five or six years of experience - but none of it in kernel mode - are only marginally better than kids in either of the above regards (and they cost a lot more).
Yes, people who write drivers often leave for other jobs, dumping their code on other people for maintenance. That's not because they're 18 year olds who don't have a clue, though. Au contraire; it's because driver developers always have a wealth of opportunities to choose from, and who wants to maintain old code instead of writing something new?
IANAL, but I've been involved in legal matters and talked to lawyers a bit. There's a very difficult distinction involved here that I'll try to clarify a little. The law doesn't recognize actual intent or state of mind, rightly holding these things to be unknowable in any specific instance. However, the law does recognize that the maker of a tool or provider of a service "should have known" how that tool/service might be used. It's very similar to the standard of diligence applied in many other areas. For example, libel/slander cases often hinge not on whether the accused did know that a statement was false, but on whether they should have known and failed to exercise due diligence in checking their facts. Ignorance is not necessarily a permissible excuse under the law, especially when the claim of ignorance is either facile or tantamount to professional malpractice.
With respect to software, I think the application of this principle is pretty obvious. The person who uses a software tool illegally always bears some responsibility; the question is whether the software author is responsible as well as - not instead of - the user. This can pretty much only be true when the maker of software "should have known" that their software would be used in such a manner, that such use could have been prevented without undue burden or compromise of other functionality, and that the author nonetheless did nothing to prevent it. The phrase "should have known" is of course vague, but I think people who work in a field generally have a pretty strong consensus on what's common knowledge and what's not. What one person in the field should have known, is what the majority of practitioners do know or could figure out in a jiffy.
This definition obviously does not indict word processors or other common types of software. It's not even clear that it indicts something like SATAN, which the author deliberately tried to present to system administrators and such as a way to improve security. I think the line gets crossed with something like Back Orifice, which was very obviously pushed primarily as a way to hack systems; any claims about it being a remote administration tool are obviously accompanied by a smirk and a wink, which would only piss off judges and juries. Even if the tool's primary purpose was legal and positive, it's pretty bleeding obvious that it can also be used illegally and negatively. Some announcement of its presence on a system would discourage the latter use while in no way interfering with the first, and the absence of such announcement could readily be construed as an indication of the author's lack of professional diligence (remember, we can't impute malice because that comes down to a matter of concrete intent).
I think network-attached storage is a fine idea and the "right solution" for many things, but I just have to add a rebuttal here anyway.
Network-attached storage is faster than local storage if your network (including the protocol stack) is fast enough and your local-storage subsystem (including its own separate protocol stack) is slow enough. That's a totally useless claim. It's like saying that a train is faster than a car, leaving out the part about the train being an unloaded bullet-train engine on an empty track and the car being a Yugo stuck in New York traffic.
In actual fact, the raw bandwidth of modern storage interconnects (e.g. UW SCSI, FC) is higher than that of most network interconnects (e.g. 100baseT) for which the adapter cost is similar. In addition, the protocols used for storage (e.g. SCSI, the various layers of FC) are more suited toward that task - duh - than are the protocols used for networking (e.g. TCP/IP). There is no reason in hell that it should be faster to use network interconnects and protocols to access your storage than to use storage-specific interconnects and protocols.
Why might it appear that network-attached storage performs better? I can think of at least three reasons right off the top of my head:
At this point I should disclose my own biases. First, I work for EMC. That's not by choice - the company I was working for got bought out - and I'm often not thrilled about it, but the pay is good. In particular, I don't buy in to all of EMC's arrogant "storage is the center of the universe and the Symmetrix is the ultimate storage device" attitude, and I heartily dislike our own Celerra NAS product even though it blows the doors off NetApp in terms of performance and scalability. Secondly, my professional areas of interest include distributed, cluster, and SAN filesystems, so I of course have some fairly strong opinions on such matters. That said...
I think that once we start seeing true, mature, multi-platform shared-storage filesystems, NAS will start to seem much less appealing. Why pay for NAS when you can just add software to your existing hardware investment and get all the sharing with almost all the performance of local access? Now all we need is a decent implementation of such a filesystem.
- USB is based on a model of hosts polling devices. This allows for cheaper device implementations, because devices don't need to initiate transactions, but makes the host-side implementation more complex. It's a good fit when you have several dumb devices and the polling latency doesn't matter - mice, keyboards, stuff like that.
- 1394 is more peer-to-peer, with devices able to initiate transactions independently. This makes device implementations more costly and host implementations less so. It's a good fit when you only have one or a few devices, when the polling latency matters, or when the device is connected to more than one machine.
My point, besides the obvious complementary nature of the two approaches, is that Intel has a much higher market share in motherboard chipsets than in consumer electronics. Of course they're going to push the host-centric solution, because they can bury a lot more profits for themselves in the cost of a motherboard.>I'd like to see some progression on IEEE-1355.. I dunno offhand what the status of work on 1355 is, but it's a far more exciting technology than either USB or IEEE-1394.
It sounds interesting, but I'm not convinced yet. How many nodes does it support on a simple loop/bus/whatever without added-cost routers/switches. How hot-pluggable is it? Does it support isochronous transfers?
I have the feeling that 1355 may be a truly great thing...for another niche. It may be a mistake to push it as an alternative or replacement for 1394, just as it is/was a mistake to push USB - a perfectly wonderful thing in its own niche - the same way.
>Intel makes the most common PC chipsets
How convenient for Intel, that they can hide the USB2 implementation cost in higher chipset prices (hint: more than the $0.25/device Apple et al are charging for 1394). Even if USB2 were technically superior to 1394 - which it's not - I'd be leery of adopting a "standard" controlled by a single manufacturer over one approved by IEEE. That goes double if the manufacturer is Intel.
Maybe VIA or someone will integrate 1394 on their motherboards instead of USB2. That would be great.
>Apple demands one dollar per firewire chip in royalties.
At least it's an honest, up-front charge. The "Intel tax" on USB2 is likely to be much higher, but hidden in things like increased motherboard/chipset prices. I'll gladly pay a buck for the difference between an IEEE standard and yet another Intel pseudo-standard, and I think most educated consumers would as well.
>But in lecture they told us that the OS has two functions (ok more like 1.5 functions):
;-)
>1). Load and execute a user program
>2). Provide an abstraction for the machine's hardware so that a user program can access it.
I think this is an argument for defining "OS" and "kernel" separately. The syscall interface provided by a kernel isn't really an abstraction of the hardware any more - not for a couple of decades. It's just an API, really, and not usefully different from other APIs; the fact that this particular API involves traps into a privileged processor mode really doesn't count for much. Do most people even know what's different about, say, open() and fopen()?
I'm not disagreeing with you, just trying use what you said as a jumping-off point for my own agenda du jour.
Opinions are like...well, you've all heard that one. ;-) Here's mine.
Several posters have already tried to make a distinction between "kernel" and "OS", and I think this distinction is becoming more and more accepted in the computing community. In five years it seems likely that nobody but dinosaurs will consider the two terms interchangeable.
To me, an OS is the set of software that makes hardware suitable for its intended application(s). This makes the definition very relative to what the hardware's intended applications actually are. Some examples:
- For an embedded hard-realtime control system, there might be little or no OS to speak of. The hardware is already adequate for its "application" which consists of hardware-specific monitoring and control code.
- For a "softer" kind of embedded system such as a touch-screen ATM, the OS consists of some hardware abstraction and some tools to write a very limited class of applications.
- For a general-purpose workstation or PC, the OS has to provide a very high level of abstraction and functionality to support a very broad class of applications.
Since nobody here ever seems to care about or even recognize the existence of computers that aren't on the desktop, I'll expand a little on that last example. I think a desktop OS can and should include things like libraries for GUI and sophisticated IPC functionality, because those are now elements of the dominant application paradigm for that class of devices. Some might think that something like a JVM is also included, but I don't agree...not for a couple more years. Editors, compilers, etc. are definitely _not_ part of the OS in my opinion; they are the applications that define what an OS for that platform is or should be. Think of it as a tree formed by application dependencies on libraries or services, library dependencies on kernels or other libraries, etc., with the hardware as the root. That part of the tree extending from the root and required by the majority of leaves is what I'd call the OS.Defining kernel is another problem. The standard definition is "code that runs in a privileged processor mode". This definition has a few weaknesses - it would make everything in our hard-realtime example "part of the kernel" and it doesn't distinguish between loadable and permanent code - but overall it's pretty good. Perhaps a slightly more accurate though more cumbersome definition would be "the privileged monolithic code which maps between the actual hardware and a set of well-defined abstractions of that hardware [e.g. virtual memory and device driver interfaces]".
Several people have pointed out that patents like these not only won't stand up in court, but that they're not even intended to. I'd like to expand on that a little.
I remember reading somewhere that a patent-office official had publicly admitted that they couldn't keep up with the flood of applications and were as a matter of policy allowing dubious patents through in the hope that the courts would sort things out. Whether the admission was real or just a figment of my imagination, this is clearly what the patent office is doing.
Patents are supposed to be (a) innovative, and (b) non-obvious, among other criteria. This patent is obviously neither, and there are enough other companies with enough legal muscle to ensure that it's never enforced, so I don't think it's much to worry about. The danger comes when a patent is granted on something obscure and the only people who care are little guys who don't have the resources to fight it successfully in court by themselves.
This brings me to my other point: patent fights. It's very common nowadays to respond to an accusation of infringement by pulling out a few of your own. "Oh yeah? Well, you're infringing our patents X, Y, and Z. Are you sure you want to take this to court?" That is what's really behind a lot of the "preemptive patenting" to which several other posters have referred. One of the tools of the high-tech business is developing a patent portfolio not so those patents can actually be used to club others over the head, but to avoid being clubbed oneself. Companies have been bought just to pad patent portfolios. It's sick, I know. I'm not defending the practice, just reporting it.
Computing has been pretty good for my real life. My first two serious romantic relationships started on M-Net, as did a long-standing friendship which was the critical contact allowing me eventually to leave a dead-end job in Michigan for what turned out to be a fairly rewarding career in Massachusetts. After that move, I met the woman who is now my wife, via alt.personals, and we exchanged email for several months before we met IRL. During a hiatus from that relationship before we got married (don't ask) I had another brief relationship, started this time on LambdaMOO.
Those are my credentials as a veteran of on-line romance. Now, the point I want to make is that the net is just a medium. To me, these relationships I've had aren't "net relationships" any more than using a phone to communicate makes them "phone relationships". They're relationships with people and the medium doesn't really matter.
There are many people who seem to develop an online persona that's different from their RL one. I'm not just talking about the sort of contextualization that causes us to interact differently with our children in the back yard and our boss at a cocktail party; I'm talking about something that's almost clinically recognizable as multiple personalities. These people often fear "crossover" between their real and virtual lives, and resist bringing the two together, because of what people may discover about their own "other self". Does this sound like a formula for long-term success and stability, romantic or otherwise? Obviously not. Most people who are online long enough eventually outgrow this phase and learn that the proper emphasis in "being yourself online" is on "being yourself" rather than "yourself online". People who maintain the separation too much or too long need to figure out what's so wrong with their real lives that they rely on their virtual lives as a refuge. Only then, IMO, can they expect to get anything substantial out of their interactions online.
>Writing is much faster as only updates are appended to a log
That sounds like a description of a log structured file system, which is related to - but not the same as - a journaling file system.
>We have redundant power supplies, hard drives, and many other pieces of hardware. I am thinking it may be good for developpers, at any rate, to use redundant kernels.
>...
>Interrupt in service: a few clock cycles
Sorry, but this doesn't work. You'd have to replicate the entire kernel address space including that used by drivers and on behalf of user programs for it to be effective. Many crashes actually result from corruption of some part of kernel memory, so if the two kernels share data they'd both crash at once. In addition, because the in-kernel data structures kept on their behalf might be different (if the two kernels were precisely identical they'd also crash in tandem) the user programs would have to be duplicated too. Now you've halved your memory and CPU resources, plus you're effectively doing a context switch "every few instructions" to go from one kernel to the other. Your performance is going to be totally abysmal.
The solution? Do what fault-tolerant systems already do and replicte the hardware as well. Been there, done that, works OK but gives lousy performance/dollar compared to non-FT alternatives. If you don't want to pay that premium you can go with a clustered highly available system such as the ones I once helped develop. Unlike an FT system, an HA system will allow an interruption when a component fails, but the duration of that interruption will be very short relative to a "vanilla" non-FT non-HA system. Also, in the absence of failures the component nodes of an HA cluster (a well-designed one, anyway) are able to process their own independent workloads instead of sitting around idle or duplicating each other's work.
>Hacking the kernel is supposed to be hard and tracing crashes given minimal information is a big part of the fun and attraction of ``iron man'' programming
That's fine if your goal is to compensate for deficiencies elsewhere in your life by making yourself feel like an "iron man" programmer. If your goal is instead to produce working quality kernel code, you eventually ask yourself "why make an intrinsically difficult task even more difficult by not using the best tools available"?
If self-flagellation or self-denial are good things, might as well go all the way, right? Go build your own computer...from sand and copper ore, using no tools but those you make yourself. Come back when you're done.
>...has to do with how many memory different places in the cache each memory address can reside
That's a very good description. Thank you.
There's also a rule about the relationship between associativity, cache size, and hit ratios. It's quoted in H&P, but I can't quite remember it; can anyone else help out? I'm tempted to say "an N-way associative cache of size X will generally achieve hit ratios similar to a direct-mapped cache of size X/N" but that seems a little too optimistic.
>This isn't baseball, you don't have to worry about things like point-shaving... if companies selling their own derivatives bothers you, don't buy them -- no company in their right mind would "take a dive" to make money off their own derivatives
I'm not sure I agree with this. Companies don't have minds, right or otherwise. Officers of companies have minds, and it's not hard to imagine unscrupulous officers manipulating stock prices in ways that benefit them but not their stockholders. It's not even hard to imagine them getting away with it; corporate officers have gotten away with worse things quite a few times.
On the other hand, he does make some good points:
- There really is a problem with how options are accounted for, and MS does take advantage of this "legal lag" more than most.
- Selling options on your own stock - especially puts, but also calls - just doesn't seem right and should probably be illegal.
- Having to pay a $4M settlement to an internal auditor who was fired and then invoked the whistleblower act seems really fishy to me.
There seems to be a good chance that MS really is cooking the books even more than is generally allowed (which is still way too much IMO). It's certainly not proven, and probably won't be by this author, but there seems to be ample reason to look into the matter more carefully.>There is general problem with how companies have to account for stock options given to employees.
That was actually one of the author's points.
What's the solution? Forcing companies to account for all granted options as income is really not quite right, because many of those options will in fact never vest. The fairest thing would seem to be a requirement for a "good faith" estimate of what percentage of options will vest, based on industry averages and/or prior experience at that company. That portion would then have to be accounted as income. It's no different really from many other things in a company's financial statements that are actually just estimates.
>'Creative accounting' is used by most major corporations, Billy G didn't invent it.
I do hope you're not implying that we should just not try to enforce any kinds of standards for accounting. That would be a classic example of the "excluded middle" fallacy, so obvious even the average slashdotter could see through it.
Sure, creative accounting has been around for a long time and many companies get away with a certain amount of "creativity" within the limits that we do set. But some companies - Sequoia and KSR come to mind - don't get away with it because their practices have gone beyond creativity into outright fraud. If we are to allow those companies to fail for their dishonesty, why should Microsoft be held to a more lenient standard?
We may not be able to make everyone perfectly honest, but we can prevent or discourage some of the most blatant forms of corporate dishonesty and that's what this article is about.
>Both stock buybacks and stock splits have long been considered legitimate tools
Buybacks and splits, sure, but how about selling put options on your own stock? That's just sleazy, and I'm amazed it's even legal.