There is something almost treasonous about a linux kernel hack whose documentation's primary format is msword+ppt. Particularly when the html links are broken.
Probably the best thing you can do for yourself is to keep a an open mind to submissions. Additional features that don't compromise your core agenda can turn out to be assets, Every so many revision cycles you can do a cleanup pass to prune out the superfluous side features that didn't prove themselves over time.
I would recommend keeping firm but open-minded control of exactly what goes in. Don't be afraid to say no. I don't see a fork in the project as being a threat most of the time. To reder it more or less harmless, register a trademark on your project name, so that the fork will not confuse your users. If their fork thrives more than your own, maybe their ideas were better than you thought. In which case, you can probably merge the two forks into a stronger project. Competition is good in the free software world. It takes nothing from you, while pushing the ideas forward more swiftly.
If you get code you don't understand, get the contributor to document it, and justify that the decreased legibility and maintainability will be getting you something worthwhile, instead of some miniscule outer-loop time savings. All of the teachings of well-documented, maintainable code count double in the open source world. I'd recommend writing a code style guide, and using it to solve diputes involving quirky style.
I don't know, this seems in line or lower than many confs I've been to. Many of them, however, have provided substantial student discounts. My best advice is, if you are involved in the field actively, you can probably get your home department to underwrite the entrance fee, particularly if you're willing to road trip there.
I may be wrong, but it seems to me that up2date in its current form is hopelessly married to Red Hat's services, and not a generally applicable piece of software. If I am correct about this, I can hardly see it as a free software victory when development money is going to improve such a limited and vendor specific program. The most obvious effect of this development would be to take the demand off of RedHat's servers, and put it on those of its users. A shrewd technique, but not exactly a public service. BitTorrent development from this project might well be a great help to the community, however.
It's kind of a catch 22 at this point. Blind people will probably be able to see in several years with the aid of computerized sensors so we should be able to push technology as though blind people could see now, realizing that they will benefit from all of this in a matter of years...but...if you do that...blind people who have no alternative now will actually be unable to function in any technical environment.
I don't really buy the theory that a more visual interface to technology is more advanced. In fact, I tend to believe the opposite. Good capable interfaces should be able without loss of functionality, of interaction through any number of presentation layers, whether they be visual, auditory, tactile, or programmatic. This allows for more versatility, automation, mobility, and human multitasking. I admit that there are some tasks that seem much easier with a visual interface. But I also believe that once we've researched other interface families as fully as we have GUIs, that this may not be the case. I think these kind of efforts will pay off a great deal for everyone, once we realize that visual interfacing is not always the best choice for a task.
First off, if you can pull it off, get the degree. I haven't worked any job after school that did not list a Bachelor's degree in something as a minimum requirement. Also, a formal program will fill in a lot of the holes that a self-directed education can leave. I think that a degree program tends to complement experience well for a broad and versatile knowledge of the field. But, it seems from the fact that you're even asking that getting the degree may not be an option. In this case, the strategies for staying competitive are mostly the same as the one that the degreed folk of the world use. You just start out with more to make up for. Certifications are probably a good idea, although I find them distasteful. When screening resumes, an employer likes to see some quantifiable metrics of knowledge, in addition to experience and signs of good character. It might be good for you to focus your qualifications on sectors of the field where degrees have been traditionally optional. Networking has always seemed this way to me. Cisco certification might be a very decent safety net. If you want real security in this market, I hear Oracle certification is sort of a magic bullet. As for staying in software with no degree, I know of no fool proof strategies. Just stay current, be lucky, and nail every interrview you get.
What exactly does this have to do with anything? Only two of the systems being benchmarked in this study are 1U servers. I see no reason why the only PC server represented needs to be a 1U system, particularly since this means using slow CPUs.
What exactly do you expect Xinet to use for benchmarking?
Well, for the kind of information they want to give their customers, I'd expect exactly what they did. For meaningful benchmarks to give a real sense of system capabilities, the answers are quite different, and I don't feel like going into it. I think Xinit had good intentions, and is not not responsible for other people trying to extract more meaning than is present in their data.
1. They used an old dual-750Mhz Fire 280R when Sun doesn't even have base configs for 280Rs with that CPU anymore. How bout using up-to-date machines?
2. Strangely, they chose to use third-party Gig-E cards rather than Sun's own, quite good Gig-E hardware. This alone could be enough to ruin the validity of the benchmarks. This is probably because they chose to focus on Gig-E over copper, a strange choice in and of itself.
3. The one PC platform box was a dual PIII 1.4Ghz. Not exactly the performance leader in dual CPU PC servers.
4. The benchmarks were all runnning one server app, Xinet's own fullpress.
All these benchmarks show, is that one app, from one developer ran faster on the Apple Xserve than on some selected, out-of-date, hardware from other vendors. To all appearances, Xinit was not doing a platform cometition so much as a random benchmark with hardware that they happened to have one hand. The number of variables that could invalidate the results entirely is just silly.
Apple is really kicking into high gear with the same kind of galling behavior that has angered much of the free world at Microsoft over the years: using a position of power and capital to limit choice in the marketplace.
Historically, Apple has done a decent job of trying to build its success on the strengths of its hardware and software platforms, and should be commended for this. Now, it looks like they are willing to do what they can to force consumers to operate on their hardware no matter what. Previously, Apple's more cut-throat decisions could be seen as specifically targetting Microsoft and company, but the primary victim of this kind of tactic is the consumer.
The most galling thing about this is how this treats Apple's own customers. By buying up this firm, they picked up a non-trivial group of Windows users as customers. They way they greet these new customers amounts to saying, "Thanks you for buying Emagic. Sadly, your choice in platforms doesn't fit Apple's plans for niche market domination. Please reward us for canceling support for the tool you value by buying one of our machines. Otherwise, go check your own filesystems."
I've said it before, and I'll say it again, Apple seems to be shooting itself in the foot by getting stuck on hardware. By sacrificing sales of software to non-Apple owners, they are vastly limiting their potential income. I firmly believe they are getting much better margins on their software products, which suggests that they really ought to be using the hardware to sell the software, not vice-versa.
Apparently, when compiling Motif apps on Solaris, the application will crash without cause unless libXm is the first lib you link in. This is an ancient, but still unfixed bug. It took me forever to figure out what was wrong with a program because of this.
This is one of the first times I've seen someone in the open-source community try to use fear-uncertainty-doubt to get their user base to upgrade whether they need to or not. It turns out, that for all Theo de Raadt's sense of urgency that everyone should upgrade, we're not vulnerable at all where I work, because we disable auth mechanisms that we are not using. I tend to believe that Theo knew that this would effect less than half of the ssh community. Even for most of us with it compiled in, there is a one-line workaround that could be deployed much more quickly than a new version. While the new privilage separation code sounds like a really good idea. Still, to me the whole drama seems like an attempt to provoke the whole community to upgrading when they really didn't need to.
In this case, you could probably apply the Patent Office's guidelines on what is patentable (i.e. innovation, non-obviousness, etc.). Of course it recently seems that the Patent Office has been ignoring these rules themselves, but they are a starting point.
Another question to yourself could be is the old company ever likely to notice or care about the use. Chances are the suits in the company are never going to notice the cool hacks internal to their software well enough to recognize them as a resource worth defending. In most cases where they would, they probably try to patent everything as they write it. Noticeable external features are another story, of course, but implementation methods are often below lawyer radar.
Also, if it an implementation detail, the odds of them knowing it is present in your product without source code is slim, so if they do decide to patent the technique, you should at least have time to respond.
True, true. I think at current it takes ~10 games for microsoft to break even with their current subsidy, although I could be wrong. Being able to buy 10 games before Microsoft has a chance at profit isn't too bad. But again, I think this is only a good idea if you like the machine and will use it. Basically, you can buy it with a decreased Microsoft-guilt factor.
Ah, but by buying one, you encourage them to manufacture more, and thus lose more. And you encourage them in the false belief that they will someday break even. They end up investing even more money in developing game hardware that they will never make profitable.
I am entirely joking. From my point of view, you should buy the x-box if you think it is a neat toy that you will use. Costing Microsoft money is just a happy little bonus.
We also know that a purely private organization, without the support and involvement of governments from around the world, will not be able to carry out thes mission assigned to ICANN (if you believe that mission requires the agreed participation of all the relevant infrastructure providers). ICANN has no guns, and no soldiers; it has no coercive power.
Something tell me before too long we can expect to hear dark rumors of ICANN building a droid army to deploy against the shining republic of the IETF.
Seriously, though, it is shocking how poitical they can try to make a system whose entire job is to associate names and numbers. For something that is essentially a hack (put the fate of the internet on the backs of a handfule of individual servers, yeah, good idea), they sure seem intent on turning it into the basis for a UN-scale political swamp.
..but conscience action. As seen in this snippet, they know they will be putting small operators out of business to make sure the RIAA gets what it wants:
Webcasters and broadcasters asked that the Librarian reject the CARP's approach and provide them with an option to pay a rate based on a percentage of their revenues, rather than a per-performance rate.
...
Finally, the CARP noted that because many webcasters are currently generating very little revenue, a percentage of revenue rate would require copyright owners to allow extensive use of their property with little or no compensation.
Well, this is not a project I'm working on any more, and management was dead-set against any real attempt to fix the problem. This was an application in use by customers, so they expected quick fixes for the bugs they found. The company was on the cheap side, so they didn't want to dedicate any staff time for the rewrite that the system desperately needed. I think applying modern programming practices would have taken it from ~500000 lines of code down to ~100000. They also denied any of my proposals to reorganize, document, or increase the quality of the codebase in any way. They were dead set on the test/bugfix paradigm. This might have something to do with the short period I chose to remain with the company.
One project I was working on made it pretty much impossible for the number of bugs to go down. The codebase was about 15 years old, about half a million lines of code, and maybe 10,000 global variables. Testing would identify a bug. A programmer would find the problem and fix it. Then three other features, wriiten years ago assuming that the bug was standard behavior, would break. The people fixing these bugs were often ignorant of the efforts of the last programmer, so as often as not the would go in and re-enable the old bug. Even if they didn't, their fix would break something else. Spaghetti code such as is common in some of these old code bases is often harder to debug than it would be to rewrite.
Hard disks have a high MTBF when compared to existing media,
I can only assume, if you meant for this to support your argument, that you mean a low MTBF. Also, in my experience, VHS tapes start "failing" (i.e. losing quality) on the second or third viewing.
I'm sorry, but this title makes me think back to the old days of the Dukes of Hazzard. I can just picture Bill and Co. sneaking into the county to sell some copies of Windows, and then hauling ass for the county line to get away from Boss Hog. Then they'd taunt him from the other side of the county line (considerately rendered in white paint).
Of course, at least the Dukes were "good old boys, never meaning no harm".
Slashdot Mirror
There is something almost treasonous about a linux kernel hack whose documentation's primary format is msword+ppt. Particularly when the html links are broken.
That article was a little bit too much opinion, not enough information. This one's a little better:
President's Advisor Predicts Cyber-Catastrophes Unless Security Improves
Just to ease the suspense, he still comes across as a bit of a loony, but at least there is enough meat in the article to properly discuss.
Probably the best thing you can do for yourself is to keep a an open mind to submissions. Additional features that don't compromise your core agenda can turn out to be assets, Every so many revision cycles you can do a cleanup pass to prune out the superfluous side features that didn't prove themselves over time.
I would recommend keeping firm but open-minded control of exactly what goes in. Don't be afraid to say no. I don't see a fork in the project as being a threat most of the time. To reder it more or less harmless, register a trademark on your project name, so that the fork will not confuse your users. If their fork thrives more than your own, maybe their ideas were better than you thought. In which case, you can probably merge the two forks into a stronger project. Competition is good in the free software world. It takes nothing from you, while pushing the ideas forward more swiftly.
If you get code you don't understand, get the contributor to document it, and justify that the decreased legibility and maintainability will be getting you something worthwhile, instead of some miniscule outer-loop time savings. All of the teachings of well-documented, maintainable code count double in the open source world. I'd recommend writing a code style guide, and using it to solve diputes involving quirky style.
I don't know, this seems in line or lower than many confs I've been to. Many of them, however, have provided substantial student discounts. My best advice is, if you are involved in the field actively, you can probably get your home department to underwrite the entrance fee, particularly if you're willing to road trip there.
I may be wrong, but it seems to me that up2date in its current form is hopelessly married to Red Hat's services, and not a generally applicable piece of software. If I am correct about this, I can hardly see it as a free software victory when development money is going to improve such a limited and vendor specific program. The most obvious effect of this development would be to take the demand off of RedHat's servers, and put it on those of its users. A shrewd technique, but not exactly a public service. BitTorrent development from this project might well be a great help to the community, however.
It's kind of a catch 22 at this point. Blind people will probably be able to see in several years with the aid of computerized sensors so we should be able to push technology as though blind people could see now, realizing that they will benefit from all of this in a matter of years...but...if you do that...blind people who have no alternative now will actually be unable to function in any technical environment.
I don't really buy the theory that a more visual interface to technology is more advanced. In fact, I tend to believe the opposite. Good capable interfaces should be able without loss of functionality, of interaction through any number of presentation layers, whether they be visual, auditory, tactile, or programmatic. This allows for more versatility, automation, mobility, and human multitasking. I admit that there are some tasks that seem much easier with a visual interface. But I also believe that once we've researched other interface families as fully as we have GUIs, that this may not be the case. I think these kind of efforts will pay off a great deal for everyone, once we realize that visual interfacing is not always the best choice for a task.First off, if you can pull it off, get the degree. I haven't worked any job after school that did not list a Bachelor's degree in something as a minimum requirement. Also, a formal program will fill in a lot of the holes that a self-directed education can leave. I think that a degree program tends to complement experience well for a broad and versatile knowledge of the field.
But, it seems from the fact that you're even asking that getting the degree may not be an option. In this case, the strategies for staying competitive are mostly the same as the one that the degreed folk of the world use. You just start out with more to make up for.
Certifications are probably a good idea, although I find them distasteful. When screening resumes, an employer likes to see some quantifiable metrics of knowledge, in addition to experience and signs of good character.
It might be good for you to focus your qualifications on sectors of the field where degrees have been traditionally optional. Networking has always seemed this way to me. Cisco certification might be a very decent safety net. If you want real security in this market, I hear Oracle certification is sort of a magic bullet.
As for staying in software with no degree, I know of no fool proof strategies. Just stay current, be lucky, and nail every interrview you get.
Actually, when it comes to 1U servers, it is.
What exactly does this have to do with anything? Only two of the systems being benchmarked in this study are 1U servers. I see no reason why the only PC server represented needs to be a 1U system, particularly since this means using slow CPUs.
What exactly do you expect Xinet to use for benchmarking?
Well, for the kind of information they want to give their customers, I'd expect exactly what they did. For meaningful benchmarks to give a real sense of system capabilities, the answers are quite different, and I don't feel like going into it. I think Xinit had good intentions, and is not not responsible for other people trying to extract more meaning than is present in their data.
1. They used an old dual-750Mhz Fire 280R when Sun doesn't even have base configs for 280Rs with that CPU anymore. How bout using up-to-date machines?
2. Strangely, they chose to use third-party Gig-E cards rather than Sun's own, quite good Gig-E hardware. This alone could be enough to ruin the validity of the benchmarks. This is probably because they chose to focus on Gig-E over copper, a strange choice in and of itself.
3. The one PC platform box was a dual PIII 1.4Ghz. Not exactly the performance leader in dual CPU PC servers.
4. The benchmarks were all runnning one server app, Xinet's own fullpress.
All these benchmarks show, is that one app, from one developer ran faster on the Apple Xserve than on some selected, out-of-date, hardware from other vendors. To all appearances, Xinit was not doing a platform cometition so much as a random benchmark with hardware that they happened to have one hand. The number of variables that could invalidate the results entirely is just silly.
Apple is really kicking into high gear with the same kind of galling behavior that has angered much of the free world at Microsoft over the years: using a position of power and capital to limit choice in the marketplace.
Historically, Apple has done a decent job of trying to build its success on the strengths of its hardware and software platforms, and should be commended for this. Now, it looks like they are willing to do what they can to force consumers to operate on their hardware no matter what. Previously, Apple's more cut-throat decisions could be seen as specifically targetting Microsoft and company, but the primary victim of this kind of tactic is the consumer.
The most galling thing about this is how this treats Apple's own customers. By buying up this firm, they picked up a non-trivial group of Windows users as customers. They way they greet these new customers amounts to saying, "Thanks you for buying Emagic. Sadly, your choice in platforms doesn't fit Apple's plans for niche market domination. Please reward us for canceling support for the tool you value by buying one of our machines. Otherwise, go check your own filesystems."
I've said it before, and I'll say it again, Apple seems to be shooting itself in the foot by getting stuck on hardware. By sacrificing sales of software to non-Apple owners, they are vastly limiting their potential income. I firmly believe they are getting much better margins on their software products, which suggests that they really ought to be using the hardware to sell the software, not vice-versa.
Apparently, when compiling Motif apps on Solaris, the application will crash without cause unless libXm is the first lib you link in. This is an ancient, but still unfixed bug. It took me forever to figure out what was wrong with a program because of this.
This is one of the first times I've seen someone in the open-source community try to use fear-uncertainty-doubt to get their user base to upgrade whether they need to or not. It turns out, that for all Theo de Raadt's sense of urgency that everyone should upgrade, we're not vulnerable at all where I work, because we disable auth mechanisms that we are not using. I tend to believe that Theo knew that this would effect less than half of the ssh community. Even for most of us with it compiled in, there is a one-line workaround that could be deployed much more quickly than a new version. While the new privilage separation code sounds like a really good idea. Still, to me the whole drama seems like an attempt to provoke the whole community to upgrading when they really didn't need to.
In this case, you could probably apply the Patent Office's guidelines on what is patentable (i.e. innovation, non-obviousness, etc.). Of course it recently seems that the Patent Office has been ignoring these rules themselves, but they are a starting point.
Another question to yourself could be is the old company ever likely to notice or care about the use. Chances are the suits in the company are never going to notice the cool hacks internal to their software well enough to recognize them as a resource worth defending. In most cases where they would, they probably try to patent everything as they write it. Noticeable external features are another story, of course, but implementation methods are often below lawyer radar.
Also, if it an implementation detail, the odds of them knowing it is present in your product without source code is slim, so if they do decide to patent the technique, you should at least have time to respond.
True, true. I think at current it takes ~10 games for microsoft to break even with their current subsidy, although I could be wrong. Being able to buy 10 games before Microsoft has a chance at profit isn't too bad. But again, I think this is only a good idea if you like the machine and will use it. Basically, you can buy it with a decreased Microsoft-guilt factor.
Ah, but by buying one, you encourage them to manufacture more, and thus lose more. And you encourage them in the false belief that they will someday break even. They end up investing even more money in developing game hardware that they will never make profitable.
I am entirely joking. From my point of view, you should buy the x-box if you think it is a neat toy that you will use. Costing Microsoft money is just a happy little bonus.
Call me petty, but this x-box business gives me a warm feeling in my heart. In buying an xbox, you can kill two birds with one stone:
1. Get a fairly cool game console.
2. Cost Microsoft $150+.
Talk about the best of both worlds. This is the closest we may ever come to the truly just world where Microsoft pays us for using their products.
I hope it hasn't just returned from deep space after contact with an alien intellegence that gave it great power.
Or worse, become some sort of space zombie, eating the brains from our hard-working GPS sattelites.
It could happen.
We also know that a purely private organization, without the support and
involvement of governments from around the world, will not be able to carry
out thes mission assigned to ICANN (if you believe that mission requires
the agreed participation of all the relevant infrastructure
providers). ICANN has no guns, and no soldiers; it has no coercive
power.
Something tell me before too long we can expect to hear dark rumors of ICANN building a droid army to deploy against the shining republic of the IETF.
Seriously, though, it is shocking how poitical they can try to make a system whose entire job is to associate names and numbers. For something that is essentially a hack (put the fate of the internet on the backs of a handfule of individual servers, yeah, good idea), they sure seem intent on turning it into the basis for a UN-scale political swamp.
..but conscience action. As seen in this snippet, they know they will be putting small operators out of business to make sure the RIAA gets what it wants:
Webcasters and broadcasters asked that the Librarian reject the CARP's approach and provide them with an option to pay a rate based on a percentage of their revenues, rather than a per-performance rate.
...
Finally, the CARP noted that because many webcasters are currently generating very little revenue, a percentage of revenue rate would require copyright owners to allow extensive use of their property with little or no compensation.
Well, this is not a project I'm working on any more, and management was dead-set against any real attempt to fix the problem. This was an application in use by customers, so they expected quick fixes for the bugs they found. The company was on the cheap side, so they didn't want to dedicate any staff time for the rewrite that the system desperately needed. I think applying modern programming practices would have taken it from ~500000 lines of code down to ~100000. They also denied any of my proposals to reorganize, document, or increase the quality of the codebase in any way. They were dead set on the test/bugfix paradigm. This might have something to do with the short period I chose to remain with the company.
One project I was working on made it pretty much impossible for the number of bugs to go down. The codebase was about 15 years old, about half a million lines of code, and maybe 10,000 global variables. Testing would identify a bug. A programmer would find the problem and fix it. Then three other features, wriiten years ago assuming that the bug was standard behavior, would break. The people fixing these bugs were often ignorant of the efforts of the last programmer, so as often as not the would go in and re-enable the old bug. Even if they didn't, their fix would break something else. Spaghetti code such as is common in some of these old code bases is often harder to debug than it would be to rewrite.
Hard disks have a high MTBF when compared to existing media,
I can only assume, if you meant for this to support your argument, that you mean a low MTBF. Also, in my experience, VHS tapes start "failing" (i.e. losing quality) on the second or third viewing.
there's nothing like Tivo available yet in Australia, or for that matter anywhere outside the States AFAIK.
Judging from this story, I suppose the have them in the UK.
They booked it right next door to the International PCP Conference, and the dust-heads are getting confused...
Monopolists Dropped Off At The County Line
I'm sorry, but this title makes me think back to the old days of the Dukes of Hazzard. I can just picture Bill and Co. sneaking into the county to sell some copies of Windows, and then hauling ass for the county line to get away from Boss Hog. Then they'd taunt him from the other side of the county line (considerately rendered in white paint).
Of course, at least the Dukes were "good old boys, never meaning no harm".