The response to the eFront thing really amazes me. I'm not vindicating or defending them at all -- they did some nasty shit. But I do think someone has to raise the issue of the affiliate websites' participation.
How on earth can you do business (and the ICQ log makes the excellent point that, once you bring money into the equation, it's no longer a hobby) - do business with another company and not know that their CEO has been convicted of fraud? Where's the due dilligence? ``What other companies are you working with? Can I talk to someone at some of your other affiliate sites?''
How can someone host a site like mame.dk or somethingawful.com as anything but a hobby in their spare time? Pud seems to do just fine running FC that way (and appropriately makes fun of big companies that require 50 people to do the same thing). This isn't a troll - at least 50% of those reading this should know how easy it is to run a dynamic web site, and even to host it cheaply. But $24,000 a month!?
If you're going to accept ad revenue as the way you pay rent, it seems like you need to be up on the ad industry and know what the CPM trends are. It also seems like you'd want a pretty good contract with your ad provider, so they can't just drop you if it's not working out. Especially after April, 2000.
I don't mean to sound harsh, but I really can't see anything but greed as a motivation for the sites that have been hit by this; that and a sense of entitlement thwarted. I mean, I love PA, I really do, but I could host it on my (pretty modest) salary, in my spare time. What entitles someone to it as their job?
-1, Flamebait I guess... though I really think these are important issues.
Wind river could develop an interface that allows Linux to run under/over/inbetween their RTOS. They can release the source and specifications for this interface. Anyone who wants to come along and adapt their RTOS to make use of this interface is free to do so.
Perhaps; but maybe not. For one thing, it sounds a lot like RMS is trying to make sure the GPL version 3 prevents this sort of "encapsulation" of a GPL'd component just to be able to absorb it into a proprietary system. And that's fine; it's absolutely in line with the aims of the FSF and the very particular flavor of "freedom" the GPL is designed to protect.
Another concern is, it's not clear how the Linux kernel could plug in to the hypothetical interface you describe. Remember, VxWorks components are the base layer; let's say you write a disk driver interface for Linux that talks to the VxWorks subsystem. How do you do that efficiently without linking that disk driver to VxWorks at some point? I can think of arcane methods, but it all seems to be on very uncertain legal ground with respect to the GPL.
They're taking on an point that is explicitly called out in the GPL; that of linking against GPL'd code. Every/.er who's been through the license game knows that if you link your code to GPL'd code, your code must be GPL'd too.
VxWorks is saying, gee, it'd be nice for our customers to have Linux above our RTOS to run their code on; why don't we put some shims in there and link the Linux kernel in and we'll be set (kind of like RT-Linux, I imagine). Oops, but we'd have to link, instead of using, say, pipes, so we hit the GPL linking clause.
But VxWorks has very little incentive to release their OS as open source, because of the basic economics of scarce resources -- in this case, their RTOS technology is pretty advanced, pretty stable, and they need to hold onto that lead to make money and pay programmers, etc. Happily, they do contribute to the GNU toolchain, using it for their platform and improving it (contributing back) so their customers, and everyone else, benefits. But that's because the toolchain isn't their core competitive advantage.
The article isn't FUD -- it's a legitimate point about the standoff between the GPL, which advocates fully public-domain programs as the only acceptable kind, and economics, where you must control a (naturally or artificially) scarce resource in order to make money and mantain an advantage against your competitors.
Corporations are legally required to act in the interests of their investors; they can't just say "we gave it all away and all our competitors now have our best technology, hope that's ok!". Meanwhile, low-level Linux developers are legally required to make their code freely available in exchange for the ability to link to freely available code. But that's not a good deal if your private code is better than the freely available stuff (and as an RTOS [at least], Linux ain't all that great). Hence, conflict.
VxWorks has a real lead in a lot of ways as an RTOS. I think it's great that they extend the GNU toolchain to support their platform -- while they leverage the work of others, they're committed to improving the toolchain overall so it's as good as their customers need (ok, some issues with their gcc, but...).
I think this article brings out the excellent point that the GPL specifically prevents them from doing what they want to do; link in code with the kernel (or under it) but keep the rights to their part of it. RMS has arbitrarily decided that "linking" as opposed to "piping" is the cut-off for separation of components of a computer system, so Wind River can't do the obvious Right Thing. Namely, build a solid RTOS and have Linux sit on one side of it to run not-so-critical user code, while retaining their rights to the RTOS that they developed. But seeing as RMS wants the GPL to be just this sort of political statement, Wind River is going to have to either release their market-leading, fairly-solid OS as GPL (not likely; not much incentive there), or else use something other than Linux.
I have spent mush time analysing this scenario. You see, Apple is ambitious like any company - all corporations are natural monopolists. The only thing that is preventing MS's total domination, on the other hand, is Linux and the Open Source way.
...
With the incredible combination of the rock steady core of BSD and the supple, supremely svelte GUI that is distinctive of Apples desktops, and the sublimation of Microsoft into the.NET black hole, I see no reason why Apple should not emerge as a major threat to the Linux/MS hegemony over the next 10 years.
Wow. That's like... wow. Do you have a program that generates statements like these, or are these beliefs you actually hold? It's one of the most impressive trolls I've seen on/. in awhile.
On the off chance that you're serious, your statements represent a deep lack of understanding of basic economics and the computer technology marketplace in general. But if you're serious, reply to this post and I'd be happy to discuss it with you.
If Apple wants success they'd better just get the thing ready for release--along with the PC version. Microsoft's new OEM licenses are likely to spur a lot of consumer interest in alternatives.
Um... or not.
There is very little (read: no) market interest in alternatives to Microsoft on PC's. That's because MS has a monopoly on the PC operating system, which it leverages to do several interesting things:
Bolster its monopoloies on business/offices software and internet browser software.
Keep PC hardware makers from coalescing power. This keeps PC hardware as cheap commodity products.
Keep Intel in check.
MS divides the PC hardware makers by controlling the standards (actually, they do most of their monopolizing by controlling standards; embrace and extend). For example, USB 2.0 exists almost entirely because MS doesn't control the FireWire standard. Since MS controls the hardware platform, any other OS company takes a huge risk running on PC's; they never know what MS will do to the hardware, which drivers will be closed, which specs will be difficult to implement.
Solve this and you go a long way to breaking the MS stranglehold. This business model is, however, the one real way they have innovated.
> Of course, I don't think this is the way to go - mostly because current SML implementations are damn slow, and I'm a C bigot.
You may be a C bigot:) but SML implementations aren't so bad:
Check out the results of the ICFP contest - the ML-based programs were really, really fast. (And they also worked, unlike a lot of the C and Perl solutions!).
Of course, it's too bad I'm a C bigot too, or my code might be better...;)
No, because MS Controls the PC Platform
on
OS X on x86?
·
· Score: 1
It's very interesting that most slashdot posts make very similar points regarding Apple's OS running on x86.
The problem, of course, is that this idea runs headlong into Windows, which is a bad idea. MS uses its software OS monopoly to keep the PC hardware market vendors at bay; PC's are commodities because MS decides what will be standards that they support, and they support standards that they control. This is a very new, clever (evil, IMHO) and effective business model for MS, and they pursue it vigorously. It is not simple technical merit that is slowing Firewire (iLink, 1394) from catching on -- Apple controls it rather than MS. MS would prefer USB 2, which it would have much better control over.
(BTW, Charles Fergusen's book High Stakes, No Prisoners has a lot of insights about the computer industry, from a guy who founded the company that made FrontPage and wanted to sell it to Netscape.)
Sun and Apple (and several other now or nearly defunct companies) make their own hardware and their own OS to go with it. This turned out to be a bad idea for Unices because of the lack of a common standard. For Apple, it may still be a bad idea (but I love their hardware), but at least you get a single standard. And, bless them, now you get a Unix too.
So the question is, why would it be a good idea for Apple to switch over from a hardware platform they have complete control over, to one that is completely controlled by their monopolist competitor? Remember, MS has an OS monopoly on PC's, which they leverage to control (and monopolize) two more markets: office software and internet browsers.
Since Apple doesn't make (much of) the artistic software that they do have a good market share in, their (lovely new) OS doesn't seem to stand a chance against MS's on x86 hardware.
So you have to think in terms of "what is the shape of this market, and how does that change when they do x, y, or z?" more than, "can OS sales make up for hardware sales".
Well, I doubt the extra couple years of experience gives you the argument, but I don't want to get into a pissing contest either.
... avionics or any other form of embedded systems development where the safety of people is involved. The level of peer review, design review, testing, etc. is orders of magnitude different when working with embedded systems that can affect the people's safety. Tools that you might trust for developing a programmable home thermostat would never pass muster for a heart monitor.
Listen, I'm sorry you've got an axe to grind, but I don't think you're arguing the points. I completely agree with the statements you make in this paragraph, but I still claim the management techniques are very similar; you're arguing about tools and degrees of safety. "Amount" of effort, complience, testing, etc. is different than "style". I have seen XP's style used in everything from embedded avionics (flying in an F-14) to applets; they vary wildly in their actual implementation and goals to meet, as they should. XP is not "sloppy", as you seem to imply; it's a technology of management that can be used in many circumstances, including highly reliable embedded systems.
Anyway, reply to this if you'd like to carry on a serious discussion.
Thanks for missing the point of my response. The question was:
But how can battles fought without a loss of life allow for this acquisition? Sooner or later you still end up with a bunch of humans that won't give up their possesions, so you still have to torture/slaughter them.
The Art of War, articulates a good response to this, along the lines of diplomatic coercion being the ultimate victory, with lesser victories as you have to destroy more of your opponent. These are about the philosophy of war, rather than specific strategies or scenarios that you refer to in the USAF simulations.
None of those three points you quote are obvious in and of themselves; there are other equally plausible options for each of them that Sun Tzu rejects.
Yes, these are very old techniques, pulled from very seasoned programmers. The contributions of XP are to get all those good ideas down in one place, explain it to others, and provide structural support for it.
The "Extreme" (yes, I hate the name too) comes from the way these techniques take good ideas and make them occur continuously. Over-the-shoulder coding is an extreme form of code review. Writing tests before you code and being required to pass regression tests before committing is an extreme form of code testing. Etc.
Open source does have the potential for the self-selected goodness you mention, but in practice only a few open source projects are so lucky. (I personally don't think the Linux kernel makes the cut, for example). But companies are self-selecting too; it's up to you to go find a place to work with other people who "get it" the way you do, or to hire them.
Quality software cannot be forced into existence by policies.
Maybe not, but it sure can be helped.
It must be created by talented software engineers that understand what the customer's needs are.
Really? What kind of talent should these engineers have? What techniques should they use? How should they determine what the customer's needs are? How often should they interact with customers? How should they go about their tasks?
The "talented engineers" part is a given for XP; the difference is in the methodology. There are many, many ways to go about it, and not all of them are particularly effective.
The management model that is suitable for development of microwave oven firmware is far different than what is appropriate for development of avionics for passenger airplanes.
On what do you base this claim? Most embedded systems people I know would go about the two pretty much the same way. Of course, the functional requirements will be radically different, but the process will be very similar.
Sometimes the customer doesn't have a clue as to what he wants or what software can do. In others, the customer is keenly aware of what can, and should, be done. Some customers want to have very little involvement in the process and others want to be involved on a day-to-day basis.
An excellent point, one addressed at length in XP Explained. Hence short iteration cycles, business-value focused planning sessions, and early deployment.
There are budgets to consider, also. It does not do any good to create the worlds finest inventory management program if you bankrupt your company in the process.
Yes, exactly. A large part of XP is about having a rational software engineering process that can smoothly and accurately reach its targets. XP can help reduce the creeping featuritis that plagues software projects, and prioritizes critical functionality so that if the project does get in trouble, the most important stuff is already done (i.e., the most value is added to the project earliest).
The conclusion: If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem.
True, but irrelevent. XP Explained suggests that if your manager is clueless, you simply adopt the XP methodology without telling him. You are a professional software programmer, aren't you? Do what you need to do to get the job done right.
If you managers have any understanding of the software development process, they will probably already have a development model in place that is appropriate for your project(s), customer(s), organization, and budget.
This may come as a shock to you, but that's really not the case. We are in the stone age of programming here, and we all want better tools, better techniques, and better results. These books are written by the kinds of engineers you would b0w to if they worked in your company; go read what they have to say and learn from it, then come back and help make it better.
You are probably right that it is a process du jour, but I disagree with your second claim -- perhaps I disagree that there exists a responsible graduate software engineering program;)
The first big unique thing about XP is its rejection of the "exponential cost curve" taught in most software engineering classes. Instead of trying to anticipate future requirements and design accordingly, XP advocates keeping the code simple, flexible, and solidly regression-testable, so that the cost of changing code is always cheap. In my experience, this has proven a really good idea.
The other unique thing about XP is that it gives structural support to the so-called "good habits" of software engineering, rather than relying on exceptional programmers to (hopefully) implement them. Over-the-shoulder coding is a wonderful technique that I at least hadn't tried before (your coding buddy doesn't even have to be a particularly strong coder, and it still works very well). The continuous test cycles and writing tests before code are not new, but the discipline of implementing them is most welcome. Short iterations with a focus on business value is practically unheard of -- instead, the focus is usually on getting a complete spec before moving to a rigid (and thus usually brittle) implementation, etc.
Of course XP isn't unique in one sense: some of the best programmers I've known already use these techniques in their own work. But, much as How to Win Friends and Influence People doesn't tell you anything you didn't already know, it's useful to have it all in one place.
Take a closer look at XP if you haven't; what your post points out to me is that, like other fad processes, people will probably rush to implement XP, miss the point, and denounce it as a fad instead of looking for the core contributions to the art.
Why is it that whenever a problem raises its ugly head in the US, does everyone race to get a lawyer for a few hundred dollars an hour.
Mostly because it's worth a hundred or so dollars an hour for me not to have to worry about the details. I'd much rather spend my time trying to create, innovate, and do, instead of waste tons of my time and mental energy staying out of jail -- how fortunate that I can just hire someone to take care of that! Meanwhile I can make hundreds of dollars an hour programming (which I'd prefer to be doing in the first place) with all that saved time.
Of course, since a lot of people are greedy, incompetent, or mean, and lawyers are a subset of "people", you'll see plenty of bad lawyers. The trick is to find a good one.
Noone negotiates without one, noone seems to be able to manage at all in the business world with out one.
Perhaps this is because everyone else thinks it's worth their while (and money) to have access to the knowledge and pattern recognition of someone who's seen thousands of legal situations in action and knows all the gotchas to look out for. I'm not personally going to be able to (much less want to) keep track of all that and still do everything else I'm interested in.
Some people do go to court and represent themselves, and do fine. See the ever-verbose Philip Greenspun's pages for one such account. Philip's also poked around a little at computer-aided litigation, which is a concept you might be interested in as well.
This model is flawed, its not only self perpetuating, but brings great riches to one sector of the community(legal that is) while sucking dry all others, including individuals.
How is this different from any service provider? Change "legal" to "programmers" and it still sounds about right. One of the effects of capitalism is that money flows to those who posess a unique advantage; in this case, knowledge of the law, or knowledge of programming. Lucky for you, it is easier in this society than in most to acquire a unique advantage (just file a patent application... haha, jk).
It is quickly becomming obvious that the US has more laws then it does justice, the patents issue seems to derive straight from that, patents arent really a method of protecting profits, they are an excuse to sue when someone copies your design.
Well, yes on both: patents are a method of protecting profits (the "unique advantage" part), and they are thus an excuse to sue when someone copies your design; otherwise, there goes your unique advantage and hence ability to make money.
Now, agreed, there are a load of problems in the present patent system; "submarine" patents that are secretly filed and then, when granted, used to pull the rug out from under those who've indepentently invented and implemented the invention on a large scale.
Note I said when, not if. Especially in the case of patents on current widespread technologies, that multiple companies are producing.
Again, that's a problem in the implementation of patents, not the theory. "Ordinary skill in the art" and all that. Definitely needs fixing.
The result is a legal community run amok, growing fat and rich on a culture that seems to not want to fix this ability to sue everything that crawls or walks.
Now you're just ranting. Lawyers didn't make these rules; politicians did. Your politicians. Lawyers get paid by people to make the law work in their favor as far as possible.
And don't forget why corporations often appear so greedy -- publicly traded companies (like, say, RedHat) are legally required to maximize shareholder investements, and thus profits. A company's leadership is being legally negligent if they don't go after opportunities that might come up, like ease of getting patents. Don't like that? Change the laws.
So wtf is your solution I hear you snarl?
I'm not snarling. The solution is obvious; change the system. It's happening with the music industry -- piss off enough AOL users who want their Napster and, whaddya know, their congresscritters start changing laws and putting pressure on the recording industry.
If the price of freedom is the blood of patriots, and every civilization needs a little revolution now and then, the next revolution will be fought by lawyers, and the only blood spilt will be that of their clients wallets.
Surely you regard this as an improvement? Or is it only other peoples' lives that you hold so cheap?
Good thought -- the ACE crew has created an automake/autoconf based build environment for ACE, and they're working on getting TAO fully building that way as well. That takes care of the building and installing woes, which to be sure can be a pain.
While ACE is "hard to use" at first, I think this has a lot to do with inherent complexity; the patterns and OS-level stuff it takes on are really deep issues, and aren't likely to go away any time soon. ACE does a great job reducing the accidental complexity of a system, and for that reason it's well worth the (significant) investment of learning, I think.
Honestly, though, the size of the build tree is not something I worry about as a programmer; if a gig or two of an well-designed framework are going to make my life easier and my code better (more portable, higher performance, easier to review, easier to debug, free of memory leaks), then it's a gig well spent. Besides, 80GB drives are cheap:)
(Of course, the ACE folks cheat; their quad Xeon boxen burn through a complete ACE+TAO build in a few minutes).
The ACE and TAO libraries from Wash. U. St. Louis are, in my opinion, excellent collections of code to read and understand. They're C++, which is in some ways all the more amazing.
Even better, they make use of Design Patterns, Extreme Programming concepts, and other great software engineering practices (and as an added bonus: nice, friendly, insightful discussions minus the egos on their mailing lists).
The source code is free for the taking (very liberal license), super-cross-platform, and you can buy solid commercial support if you like.
Often the large files are mirrored, so a quick search on google for either the file name or the keywords will get you to an unslashdotted version.
Of course, that's a tedious solution, so how about this: an automatic mirror finder so when/. posts a link to a big file, the system automagically does a net search for files with approx. the same size and name, and links to them too on a "possilbe mirrors" page...
All righty then, Mr. Smarty Pants, why is it good?
Well, one reason it's good is that it's become widely accepted that the "product" model for software is a bad idea. Software is not a fixed thing; instead it tends to get upgraded over time, which results in this fictitious notion of new versions being their own "products" so producers can offset the cost of improving it.
The whole idea of software as a service is sort of ludicrous.
Actually, it makes more sense to adopt a subscription (or "service") model, like customer support, since most of the cost of producing software is an ongoing kind of thing. As consumers it makes sense to have the latest version that works the best. Why not pay $x dollars a year or month and recieve continuous upgrades for the "Word service"?
.NET is not a dumb idea, nor is MS the first to think of it. In fact, it's not so different from a prettied-up apt-get plus subscription model...
<rant> MS software doesn't cost too much; it costs exactly what the market will bear. MS is not obliged to give their stuff away just because you want it -- and why on earth do you want it??? </rant>
So there's this book out there called The Armchair Economist (amazon) that I just finished reading, and from the looks of most of the comments in this thread, plenty of my fellow/. readers might enjoy it. It sheds a lot of light on how to go about reasoning about economics, happily omitting tedious theory and/or graphs. It helps answer fun, nontrivial questions like why movie popcorn is so expensive and why seatbelts increase the accident rate.
Come to think of it, enough of the political-related threads on/. end up with the same standard (but, I've recently discovered, naive) arguments about how to tax and fund things, this could be worthy of a front-page/. book review -- but by someone who can write better than me!
BTW, taxing companies that pollute to pay for cleaning up the pollution mostly just gives their money to people like landowners; read the book and find out why! (short answer: because (1) nobody owns the air, and (2) people don't mind living with pollution at the price they're paying to live there, or they'd move somewhere else [until prices dropped or everyone had left])
right! just the same way people will drive less if they raise the gas prices!
uhh... they will in fact drive less. Last time this happened, in the 70's, gas prices were being held low by the gov't, leading to really short supply. When price controls were removed, the market found a price where supply and demand met, and people ended up driving less because they were unwilling/unable to pay the higher prices. People respond to incentives, and there are pretty much always alternatives when the going gets tough.
Have you looked at ArsDigita? They seem to have a similar toolkit and biz model, and their stuff's open source too. (They do need Oracle, true, but the OpenACS project uses PostgreSQL instead).
Philip Greenspun's book (reviewed/interviewed on/.), Philip and Alex's Guide to Web Publishing (full text free online) has some interesting coverage of this stuff, too.
Well said. In your parking lot scenario, imagine that the average person can see the locks on all the cars in the lot at once, just by glancing at them. That is how I think of sites on the internet; I don't think of it as trying each door. But I do see your point.
I don't agree with your analysis of the ethics, though. I think it's perfectly acceptable to see an open vulnerability even if your eyesight is a little invasive -- like if you glance into someone's living room window and find their house is on fire. What is *not* ethical is to then do nothing about this discovery -- I believe one is then ethically compelled to report the vunerability to the vulnerable.
I think it is a mistake to assume that the person reporting the vulnerability is the first person to discover it; instead, the vulnerable should be thankful (scared, but thankful) that they can close up this exposure and start doing damage control. It's really naive to think that nobody's already taken advantage of the vulnerability just because only one person has reported it.
Slashdot Mirror
How on earth can you do business (and the ICQ log makes the excellent point that, once you bring money into the equation, it's no longer a hobby) - do business with another company and not know that their CEO has been convicted of fraud? Where's the due dilligence? ``What other companies are you working with? Can I talk to someone at some of your other affiliate sites?''
How can someone host a site like mame.dk or somethingawful.com as anything but a hobby in their spare time? Pud seems to do just fine running FC that way (and appropriately makes fun of big companies that require 50 people to do the same thing). This isn't a troll - at least 50% of those reading this should know how easy it is to run a dynamic web site, and even to host it cheaply. But $24,000 a month!?
If you're going to accept ad revenue as the way you pay rent, it seems like you need to be up on the ad industry and know what the CPM trends are. It also seems like you'd want a pretty good contract with your ad provider, so they can't just drop you if it's not working out. Especially after April, 2000.
I don't mean to sound harsh, but I really can't see anything but greed as a motivation for the sites that have been hit by this; that and a sense of entitlement thwarted. I mean, I love PA, I really do, but I could host it on my (pretty modest) salary, in my spare time. What entitles someone to it as their job?
-1, Flamebait I guess... though I really think these are important issues.
Perhaps; but maybe not. For one thing, it sounds a lot like RMS is trying to make sure the GPL version 3 prevents this sort of "encapsulation" of a GPL'd component just to be able to absorb it into a proprietary system. And that's fine; it's absolutely in line with the aims of the FSF and the very particular flavor of "freedom" the GPL is designed to protect.
Another concern is, it's not clear how the Linux kernel could plug in to the hypothetical interface you describe. Remember, VxWorks components are the base layer; let's say you write a disk driver interface for Linux that talks to the VxWorks subsystem. How do you do that efficiently without linking that disk driver to VxWorks at some point? I can think of arcane methods, but it all seems to be on very uncertain legal ground with respect to the GPL.
VxWorks is saying, gee, it'd be nice for our customers to have Linux above our RTOS to run their code on; why don't we put some shims in there and link the Linux kernel in and we'll be set (kind of like RT-Linux, I imagine). Oops, but we'd have to link, instead of using, say, pipes, so we hit the GPL linking clause.
But VxWorks has very little incentive to release their OS as open source, because of the basic economics of scarce resources -- in this case, their RTOS technology is pretty advanced, pretty stable, and they need to hold onto that lead to make money and pay programmers, etc. Happily, they do contribute to the GNU toolchain, using it for their platform and improving it (contributing back) so their customers, and everyone else, benefits. But that's because the toolchain isn't their core competitive advantage.
The article isn't FUD -- it's a legitimate point about the standoff between the GPL, which advocates fully public-domain programs as the only acceptable kind, and economics, where you must control a (naturally or artificially) scarce resource in order to make money and mantain an advantage against your competitors.
Corporations are legally required to act in the interests of their investors; they can't just say "we gave it all away and all our competitors now have our best technology, hope that's ok!". Meanwhile, low-level Linux developers are legally required to make their code freely available in exchange for the ability to link to freely available code. But that's not a good deal if your private code is better than the freely available stuff (and as an RTOS [at least], Linux ain't all that great). Hence, conflict.
I think this article brings out the excellent point that the GPL specifically prevents them from doing what they want to do; link in code with the kernel (or under it) but keep the rights to their part of it. RMS has arbitrarily decided that "linking" as opposed to "piping" is the cut-off for separation of components of a computer system, so Wind River can't do the obvious Right Thing. Namely, build a solid RTOS and have Linux sit on one side of it to run not-so-critical user code, while retaining their rights to the RTOS that they developed. But seeing as RMS wants the GPL to be just this sort of political statement, Wind River is going to have to either release their market-leading, fairly-solid OS as GPL (not likely; not much incentive there), or else use something other than Linux.
...
With the incredible combination of the rock steady core of BSD and the supple, supremely svelte GUI that is distinctive of Apples desktops, and the sublimation of Microsoft into the
Wow. That's like... wow. Do you have a program that generates statements like these, or are these beliefs you actually hold? It's one of the most impressive trolls I've seen on /. in awhile.
On the off chance that you're serious, your statements represent a deep lack of understanding of basic economics and the computer technology marketplace in general. But if you're serious, reply to this post and I'd be happy to discuss it with you.
Um... or not.
There is very little (read: no) market interest in alternatives to Microsoft on PC's. That's because MS has a monopoly on the PC operating system, which it leverages to do several interesting things:
- Bolster its monopoloies on business/offices software and internet browser software.
- Keep PC hardware makers from coalescing power. This keeps PC hardware as cheap commodity products.
- Keep Intel in check.
MS divides the PC hardware makers by controlling the standards (actually, they do most of their monopolizing by controlling standards; embrace and extend). For example, USB 2.0 exists almost entirely because MS doesn't control the FireWire standard. Since MS controls the hardware platform, any other OS company takes a huge risk running on PC's; they never know what MS will do to the hardware, which drivers will be closed, which specs will be difficult to implement.Solve this and you go a long way to breaking the MS stranglehold. This business model is, however, the one real way they have innovated.
You may be a C bigot :) but SML implementations aren't so bad:
Check out the results of the ICFP contest - the ML-based programs were really, really fast. (And they also worked, unlike a lot of the C and Perl solutions!).
Of course, it's too bad I'm a C bigot too, or my code might be better... ;)
The problem, of course, is that this idea runs headlong into Windows, which is a bad idea. MS uses its software OS monopoly to keep the PC hardware market vendors at bay; PC's are commodities because MS decides what will be standards that they support, and they support standards that they control. This is a very new, clever (evil, IMHO) and effective business model for MS, and they pursue it vigorously. It is not simple technical merit that is slowing Firewire (iLink, 1394) from catching on -- Apple controls it rather than MS. MS would prefer USB 2, which it would have much better control over.
(BTW, Charles Fergusen's book High Stakes, No Prisoners has a lot of insights about the computer industry, from a guy who founded the company that made FrontPage and wanted to sell it to Netscape.)
Sun and Apple (and several other now or nearly defunct companies) make their own hardware and their own OS to go with it. This turned out to be a bad idea for Unices because of the lack of a common standard. For Apple, it may still be a bad idea (but I love their hardware), but at least you get a single standard. And, bless them, now you get a Unix too.
So the question is, why would it be a good idea for Apple to switch over from a hardware platform they have complete control over, to one that is completely controlled by their monopolist competitor? Remember, MS has an OS monopoly on PC's, which they leverage to control (and monopolize) two more markets: office software and internet browsers.
Since Apple doesn't make (much of) the artistic software that they do have a good market share in, their (lovely new) OS doesn't seem to stand a chance against MS's on x86 hardware.
So you have to think in terms of "what is the shape of this market, and how does that change when they do x, y, or z?" more than, "can OS sales make up for hardware sales".
Well, I doubt the extra couple years of experience gives you the argument, but I don't want to get into a pissing contest either.
Listen, I'm sorry you've got an axe to grind, but I don't think you're arguing the points. I completely agree with the statements you make in this paragraph, but I still claim the management techniques are very similar; you're arguing about tools and degrees of safety. "Amount" of effort, complience, testing, etc. is different than "style". I have seen XP's style used in everything from embedded avionics (flying in an F-14) to applets; they vary wildly in their actual implementation and goals to meet, as they should. XP is not "sloppy", as you seem to imply; it's a technology of management that can be used in many circumstances, including highly reliable embedded systems.
Anyway, reply to this if you'd like to carry on a serious discussion.
But how can battles fought without a loss of life allow for this acquisition? Sooner or later you still end up with a bunch of humans that won't give up their possesions, so you still have to torture/slaughter them.
The Art of War, articulates a good response to this, along the lines of diplomatic coercion being the ultimate victory, with lesser victories as you have to destroy more of your opponent. These are about the philosophy of war, rather than specific strategies or scenarios that you refer to in the USAF simulations.
None of those three points you quote are obvious in and of themselves; there are other equally plausible options for each of them that Sun Tzu rejects.
That's interesting -- we found pair programming it the most useful part! Several other posters dislike it as well; I wonder what makes the difference.
The "Extreme" (yes, I hate the name too) comes from the way these techniques take good ideas and make them occur continuously. Over-the-shoulder coding is an extreme form of code review. Writing tests before you code and being required to pass regression tests before committing is an extreme form of code testing. Etc.
Open source does have the potential for the self-selected goodness you mention, but in practice only a few open source projects are so lucky. (I personally don't think the Linux kernel makes the cut, for example). But companies are self-selecting too; it's up to you to go find a place to work with other people who "get it" the way you do, or to hire them.
Maybe not, but it sure can be helped.
It must be created by talented software engineers that understand what the customer's needs are.
Really? What kind of talent should these engineers have? What techniques should they use? How should they determine what the customer's needs are? How often should they interact with customers? How should they go about their tasks?
The "talented engineers" part is a given for XP; the difference is in the methodology. There are many, many ways to go about it, and not all of them are particularly effective.
The management model that is suitable for development of microwave oven firmware is far different than what is appropriate for development of avionics for passenger airplanes.
On what do you base this claim? Most embedded systems people I know would go about the two pretty much the same way. Of course, the functional requirements will be radically different, but the process will be very similar.
Sometimes the customer doesn't have a clue as to what he wants or what software can do. In others, the customer is keenly aware of what can, and should, be done. Some customers want to have very little involvement in the process and others want to be involved on a day-to-day basis.
An excellent point, one addressed at length in XP Explained. Hence short iteration cycles, business-value focused planning sessions, and early deployment.
There are budgets to consider, also. It does not do any good to create the worlds finest inventory management program if you bankrupt your company in the process.
Yes, exactly. A large part of XP is about having a rational software engineering process that can smoothly and accurately reach its targets. XP can help reduce the creeping featuritis that plagues software projects, and prioritizes critical functionality so that if the project does get in trouble, the most important stuff is already done (i.e., the most value is added to the project earliest).
The conclusion: If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem.
True, but irrelevent. XP Explained suggests that if your manager is clueless, you simply adopt the XP methodology without telling him. You are a professional software programmer, aren't you? Do what you need to do to get the job done right.
If you managers have any understanding of the software development process, they will probably already have a development model in place that is appropriate for your project(s), customer(s), organization, and budget.
This may come as a shock to you, but that's really not the case. We are in the stone age of programming here, and we all want better tools, better techniques, and better results. These books are written by the kinds of engineers you would b0w to if they worked in your company; go read what they have to say and learn from it, then come back and help make it better.
The first big unique thing about XP is its rejection of the "exponential cost curve" taught in most software engineering classes. Instead of trying to anticipate future requirements and design accordingly, XP advocates keeping the code simple, flexible, and solidly regression-testable, so that the cost of changing code is always cheap. In my experience, this has proven a really good idea.
The other unique thing about XP is that it gives structural support to the so-called "good habits" of software engineering, rather than relying on exceptional programmers to (hopefully) implement them. Over-the-shoulder coding is a wonderful technique that I at least hadn't tried before (your coding buddy doesn't even have to be a particularly strong coder, and it still works very well). The continuous test cycles and writing tests before code are not new, but the discipline of implementing them is most welcome. Short iterations with a focus on business value is practically unheard of -- instead, the focus is usually on getting a complete spec before moving to a rigid (and thus usually brittle) implementation, etc.
Of course XP isn't unique in one sense: some of the best programmers I've known already use these techniques in their own work. But, much as How to Win Friends and Influence People doesn't tell you anything you didn't already know, it's useful to have it all in one place.
Take a closer look at XP if you haven't; what your post points out to me is that, like other fad processes, people will probably rush to implement XP, miss the point, and denounce it as a fad instead of looking for the core contributions to the art.
Read The Art of War, by Sun Tzu.
Mostly because it's worth a hundred or so dollars an hour for me not to have to worry about the details. I'd much rather spend my time trying to create, innovate, and do, instead of waste tons of my time and mental energy staying out of jail -- how fortunate that I can just hire someone to take care of that! Meanwhile I can make hundreds of dollars an hour programming (which I'd prefer to be doing in the first place) with all that saved time.
Of course, since a lot of people are greedy, incompetent, or mean, and lawyers are a subset of "people", you'll see plenty of bad lawyers. The trick is to find a good one.
Noone negotiates without one, noone seems to be able to manage at all in the business world with out one.
Perhaps this is because everyone else thinks it's worth their while (and money) to have access to the knowledge and pattern recognition of someone who's seen thousands of legal situations in action and knows all the gotchas to look out for. I'm not personally going to be able to (much less want to) keep track of all that and still do everything else I'm interested in.
Some people do go to court and represent themselves, and do fine. See the ever-verbose Philip Greenspun's pages for one such account. Philip's also poked around a little at computer-aided litigation, which is a concept you might be interested in as well.
This model is flawed, its not only self perpetuating, but brings great riches to one sector of the community(legal that is) while sucking dry all others, including individuals.
How is this different from any service provider? Change "legal" to "programmers" and it still sounds about right. One of the effects of capitalism is that money flows to those who posess a unique advantage; in this case, knowledge of the law, or knowledge of programming. Lucky for you, it is easier in this society than in most to acquire a unique advantage (just file a patent application... haha, jk).
It is quickly becomming obvious that the US has more laws then it does justice, the patents issue seems to derive straight from that, patents arent really a method of protecting profits, they are an excuse to sue when someone copies your design.
Well, yes on both: patents are a method of protecting profits (the "unique advantage" part), and they are thus an excuse to sue when someone copies your design; otherwise, there goes your unique advantage and hence ability to make money.
Now, agreed, there are a load of problems in the present patent system; "submarine" patents that are secretly filed and then, when granted, used to pull the rug out from under those who've indepentently invented and implemented the invention on a large scale.
Note I said when, not if. Especially in the case of patents on current widespread technologies, that multiple companies are producing.
Again, that's a problem in the implementation of patents, not the theory. "Ordinary skill in the art" and all that. Definitely needs fixing.
The result is a legal community run amok, growing fat and rich on a culture that seems to not want to fix this ability to sue everything that crawls or walks.
Now you're just ranting. Lawyers didn't make these rules; politicians did. Your politicians. Lawyers get paid by people to make the law work in their favor as far as possible.
And don't forget why corporations often appear so greedy -- publicly traded companies (like, say, RedHat) are legally required to maximize shareholder investements, and thus profits. A company's leadership is being legally negligent if they don't go after opportunities that might come up, like ease of getting patents. Don't like that? Change the laws.
So wtf is your solution I hear you snarl?
I'm not snarling. The solution is obvious; change the system. It's happening with the music industry -- piss off enough AOL users who want their Napster and, whaddya know, their congresscritters start changing laws and putting pressure on the recording industry.
If the price of freedom is the blood of patriots, and every civilization needs a little revolution now and then, the next revolution will be fought by lawyers, and the only blood spilt will be that of their clients wallets.
Surely you regard this as an improvement? Or is it only other peoples' lives that you hold so cheap?
Peace out,
While ACE is "hard to use" at first, I think this has a lot to do with inherent complexity; the patterns and OS-level stuff it takes on are really deep issues, and aren't likely to go away any time soon. ACE does a great job reducing the accidental complexity of a system, and for that reason it's well worth the (significant) investment of learning, I think.
Honestly, though, the size of the build tree is not something I worry about as a programmer; if a gig or two of an well-designed framework are going to make my life easier and my code better (more portable, higher performance, easier to review, easier to debug, free of memory leaks), then it's a gig well spent. Besides, 80GB drives are cheap :)
(Of course, the ACE folks cheat; their quad Xeon boxen burn through a complete ACE+TAO build in a few minutes).
Even better, they make use of Design Patterns, Extreme Programming concepts, and other great software engineering practices (and as an added bonus: nice, friendly, insightful discussions minus the egos on their mailing lists).
The source code is free for the taking (very liberal license), super-cross-platform, and you can buy solid commercial support if you like.
It's good stuff; check it out.
Often the large files are mirrored, so a quick search on google for either the file name or the keywords will get you to an unslashdotted version.
Of course, that's a tedious solution, so how about this: an automatic mirror finder so when /. posts a link to a big file, the system automagically does a net search for files with approx. the same size and name, and links to them too on a "possilbe mirrors" page...
Or something.
Well, one reason it's good is that it's become widely accepted that the "product" model for software is a bad idea. Software is not a fixed thing; instead it tends to get upgraded over time, which results in this fictitious notion of new versions being their own "products" so producers can offset the cost of improving it.
The whole idea of software as a service is sort of ludicrous.
Actually, it makes more sense to adopt a subscription (or "service") model, like customer support, since most of the cost of producing software is an ongoing kind of thing. As consumers it makes sense to have the latest version that works the best. Why not pay $x dollars a year or month and recieve continuous upgrades for the "Word service"?
<rant> MS software doesn't cost too much; it costs exactly what the market will bear. MS is not obliged to give their stuff away just because you want it -- and why on earth do you want it??? </rant>
Come to think of it, enough of the political-related threads on /. end up with the same standard (but, I've recently discovered, naive) arguments about how to tax and fund things, this could be worthy of a front-page /. book review -- but by someone who can write better than me!
BTW, taxing companies that pollute to pay for cleaning up the pollution mostly just gives their money to people like landowners; read the book and find out why! (short answer: because (1) nobody owns the air, and (2) people don't mind living with pollution at the price they're paying to live there, or they'd move somewhere else [until prices dropped or everyone had left])
uhh... they will in fact drive less. Last time this happened, in the 70's, gas prices were being held low by the gov't, leading to really short supply. When price controls were removed, the market found a price where supply and demand met, and people ended up driving less because they were unwilling/unable to pay the higher prices. People respond to incentives, and there are pretty much always alternatives when the going gets tough.
Just my $.02,
Philip Greenspun's book (reviewed/interviewed on /.), Philip and Alex's Guide to Web Publishing (full text free online) has some interesting coverage of this stuff, too.
From the cryptix release:
Sounds like it's named that way to get Rijmen and Daemen in there.
Zombies heersen over Belgie!
(Zombies rule Belgium!) -- Zippy the Pinhead.
Well said. In your parking lot scenario, imagine that the average person can see the locks on all the cars in the lot at once, just by glancing at them. That is how I think of sites on the internet; I don't think of it as trying each door. But I do see your point.
I don't agree with your analysis of the ethics, though. I think it's perfectly acceptable to see an open vulnerability even if your eyesight is a little invasive -- like if you glance into someone's living room window and find their house is on fire. What is *not* ethical is to then do nothing about this discovery -- I believe one is then ethically compelled to report the vunerability to the vulnerable.
I think it is a mistake to assume that the person reporting the vulnerability is the first person to discover it; instead, the vulnerable should be thankful (scared, but thankful) that they can close up this exposure and start doing damage control. It's really naive to think that nobody's already taken advantage of the vulnerability just because only one person has reported it.
Not the final word, of course...