Because either the 'i' should have been capitalized since "hardware" was followed by a period, or the period following "hardware" should have been a comma.
Since neither construction was used, the paragraph as written did not follow the conventional rules of grammar, therefore, the sic was required.
I also could have written "[hardware, i.e.,]", but that wouldn't have led to so many fruitful side discussions.
See my previous comment: Since the immediately preceding token was a period, the previous statement was contained in a completed sentence. Conventionally, this requires that the first character of the next statement be capitalized, hence the need to write either "hardware, i.e." or "hardware. I.e.". Either choice would have removed the need for the sic.
Uh, no: Technically yeast is a fungi and fungi are not animals. Nor are they plants. I invite you to do your research on biological classification, kingdoms, domains, animalia, fungi, plantae, etc.
Excellent point - as are all of your "quibbles" (which I think you use to mean "pithy and accurate observation" - at least that's the sense I get from your post:->).
I poorly expressed the point I was trying to make when I wrote "no UML". I meant something more along the lines of "no jargon", no specialized terminology or diagrams that are unfamiliar to a non-technical audience. For example, "actors" and "agents" have specific meanings in various contexts, and while developers and architects know which context is which, most customers are going to think "Angelina Jolie" and "Swifty Lazar". And educating them on your terminology may well be counter-productive. Same thing with swim lanes, fish tails, entity-relationship diagrams, etc.
They all have their place, absolutely. And in a relatively larger organization with relatively more mature processes, architects and designers would use these, and someone else (marketing? project management? product management?) would translate these to language and format suitable for customers. (As an aside, which will become quite relevant momentarily, one role of these specialized tools and jargons is to convey meaning accurately and precisely to others who lack context, for reasons of time or space or both.)
My general inclination is that if you have a smaller organization and are just starting on implementing processes, it's best to just work with the customer presentables - you don't have the cycles or resources to do both, and you need the customer-facing stuff. The danger is that a lack of precision in your designs may lead to implementation errors. Or worse, customer acceptance problems.
Hence the "checkpoint and repeat" development cycle (involving the customer if it makes sense).
But if your organization is relatively small, you gain the benefit of context and conversation: You are not capturing design for later use by people who may not even have been hired yet, but for immediate use by a team of people who are likely all living this project (and possibly nothing else).
One of the big tricks of management is figuring out which organization you are, noticing when you are changing from one to the other, and adding process maturity at the right time (read: Just early enough, and never too late).
That's a big trick. If you can pull that off repeatedly, you have a solid future ahead of you.
This is one of the first posts I've ever wanted to mod to +6.
Quick, let's grab the slashcode and make it go to 11!
Of course, that will mean converting it to use base 5, but that might be cool. Today would be the 43rd day of the 4th month of the 31014th year, for example.
Seriously, thanks - I've got a little glow of slashpride right now!
Mod parent up. With all due respect to other posters, sending the submitter to ITIL is overkill. Talk about drinking from the firehose.
I use to run a number of development teams in a systems integration and custom development shop: We took our employer's base products and toolkits and integrated them into customer environments. We did a lot of "1.0's" - typical projects were 2 to 6 weeks in length and if we ever saw them again, we lost money. We could afford one or two moderate bugs (sev 3 - functionality impaired); more than that, we lost money. We could not afford major bugs (sev 1 - all is borked; sev 2 - most is borked). And given the tight timelines, we had to be very sure that what we were developing was what the customer asked for and what the customer asked for was what the customer wanted.
We almost always made money and our customers were almost always very satisfied. We very rarely lost money, and it was usually on strategic projects (spend integration money to make more license money).
Here's what we did:
Write a high level design document describing the major components and data flows. A mix of diagrams and text. Nothing too technical, because the customer has to understand it. But it has to be enough for a senior dev to either start coding (2 week project) or write an internal-use mid-level design doc (6 week project).
Developer, tester, and writer estimate how long to do their bits based on high-level design. Project management adds some buffer (10% to 50% based on complexity).
Customer reviews design, expected ship date, signs off. (Because the design has to be fit for the customer, no UML diagrams or fancy methodologies that the customer doesn't understand. These things have their place, to be sure. But if you cannot describe it in pictures and words, it may be too complicated for you and your organization's current level of development methodology.)
Based on the high-level design document, start three simultaneous streams:
Development: Either start coding or write that mid-level design document.
Test: Write the test plan. Not the test cases. Start with the acceptance test plan. Have this signed off by the customer.
Documentation: Start putting together the major structure of the documentation. (ToC, section headings, text where necessary, etc.).
Checkpoint: The developer, tester, and writer meet to ensure that they agree that what they are each working on aligns with the others and with the high-level design. This can be a 30 minute meeting or a three hour meeting, depending on scope, etc. Most important things:
Do we align with the design?
Will we ship on time?
Add detail. The developer codes, the tester writes test cases or test scripts, the writer writes documentation.
Checkpoint: The developer, tester, and writer meet to ensure alignment.
Do we align with the design?
Will we ship on time?
Repeat "add detail" and "checkpoint" steps as necessary. Stop adding detailing when done (e.g., often the writer will finish first, then the tester, then the dev - and it's nice when it goes this way, because the tester can review the docs and make sure test plans and docs really align).
Test.
Ship.
Profit.
Handling exceptions. If at any point things start to drift out of alignment, stop. Figure it out. If the problem was the high-level design, go back to the customer. Otherwise, it's an internal issue you have to identify and correct.
VIP: Acceptance test plan. Having the acceptance test plan signed off by the customer is crucial. If they sign it off and everyone codes to it and it aligns with the high-level design and the deliverable passes acceptance, then you are done.
One thing I've left out: Change requests. They are the bane of every project under development. You need to dig in your heels and manage them properly. Work collaboratively with the
the above is simply not correct. Putting aside issues of writing style, quality, completeness, etc., along with the abomination called info pages, manpages ARE documentation
You are putting aside things that cannot be put aside. Far too may Linux man pages are brief pointers to the info info, and far too often the info pages merely rehash the inadequate content of the man pages.
To qualify as documentation, a man page must include sufficient detail to act as a reference, not merely a command line summary.
UNIX man pages were documentation - and were how I learned UNIX, back in the day. Generally speaking, the Linux user is better off with web pages than with man pages - too many Linux man pages don't cut it.
Are you lawyer? If not, stop offering legal advice. I'm not a lawyer either, so I'll just paraphrase what my lawyer told me two weeks ago: "Sure, an NDA is a good step - if it can be enforced." If you are a lawyer, please cite case law, etc., that backs up this "magic NDA" view.
An NDA is not a magic shield that will protect your ideas. At best, it is one tool among many. At worst, it is fool's security blanket.
Another tool is the provisional patent.
And another is meticulous documentation - document every meeting, every email, etc. I make some people sign NDAs - for others, I rely on the fact that I can point to a body of evidence - correspondence, journals, etc. - that show that the ideas were mine. It depends on the person, the situation, the likelihood they will sign - if you ask someone for advice, why would they sign an NDA? What, exactly, do they get out of it?
Of course we have a 29 to 1 advantage in baseball teams and all of those guys use steroids so they could be pretty tough to beat in a fight
You neglect our fifth column: 24 hockey teams, most with Canadian captains and ~50% Canadian players. I'm sure we'll be able to co-opt the Europeans as well....
The hockey players are in full body armour, with deadly weapons in their hands and on their feet. So I'm pretty sure our fifth column hockey players will take out your drug addled club wielders (hint: Use AL pitchers as fodder, since they have yet to master the club).
Your only hope is that your guys in half body armour can stay in the fight for more than a single play.
And don't even think about enlisting basketball players - unless it's for the comic relief of a slap fight among the freakishly tall....
Why would you want to use PS3s for a homebrew supercomputing cluster
IIRC, a general purpose CPU has a small data cache and a large instruction cache, coz you can never be 100% sure which instruction is likely to be executed next. PS3s have large data caches and small instruction caches, because they spend much of their time executing a small number of instructions over a large set of data, that is, graphics rendering.
If you are doing any sort of mathematical simulation, you can likely express your numerical methods in a relatively small set of instructions. And you are likely going to have hoards and scads and barrels of data.
Machines like the PS3 are perfectly suited to number crunching. If only there were some way to kit them into a Beowulf cluster....
Again, IIRC, this was the original motivation for porting Linux to the PS2 before the official kit came out: Because a cluster of PS2s running Linux made for a far faster number cruncher than anything else available for a comparable price (or a price within an order or two of magnitude).
As for writing and optimizing code, well, let's just say you made my eyes bug out with that one. If you are doing any serious supercomputing, you are ALWAYS writing and optimizing code: The point is to get the fastest possible execution so you can crunch the greatest amount of data possible and get the best possible results from your work.
In serious number crunching, the effort spent coding and optimizing is almost always going to pay off.
So I can rotate those dollars 90 degrees and they are real dollars?
Whoa, slow down there, bucko - I think you might confusing rotation with projection.
Project those imaginary dollars onto the real axis and you'll get exactly what this post is worth!
Homework assignment: Using this reasoning, show the recent financial troubles could have been predicted using simple vector analysis. Bonus points from computing the cross-product of Al Greenspan and Warren Buffet.
So I took the test and scored 90.91% (30/33)
And I'm Canadian.
Me too!
The 3 I missed.... #7, thought it was much earlier; #10, knew it wasn't A, guessed one of the others; and #33.
33 is an interesting one. I chose "debt", though I knew it was wrong, but felt it was "more right" than any of the others. Deficit would have been 100% correct, no question. I dispute the correct answer, because it is open to interpretation. I took it to mean "is spending on me exactly what I pay in taxes", which is obviously correct only for a very few. If they'd stuck in "average", that would have been fine, and while I agree you could argue it was implied, well, when words are implied the result is almost always ambiguity.
Just look at the 2nd amendment and the all the ruckus arising from its ambiguous phrasing!
He is not our ally in ensuring we can get whatever media we want whenever we want for no cost.
I beg your pardon? Why are you putting words in our mouths?
I don't want whatever media whenever at no cost. I want to buy a copy of a song or movie at a reasonable cost (pennies on the download, dimes for a hardcopy) and listen to that copy on my computer, in my car, in my house, while walking the dog, whatever, and make a backup copy just in case. And I want those things to be easy to do. Easy for me. And easy for my 75 year old Mother when she buys something.
If I want to watch a movie again and again (which is the only reason I buy 'em in the first place), then when I stick the farging disk in the farging player I want it to farging play, goldurnit! I don't want to have to watch the same warning over and over and over and over and over and OMG not again over....
And I want all works to eventually get where they should be: The public domain. Perpetual copyrights and excessively long copyrights and corporate coddling are social evils.
As it is now, I cannot
Buy a copy of a song or movie at a reasonable price.
Buy a copy of a song or movie and know for sure that I can make a backup copy.
Buy a copy of a song or movie and know for sure that I can access it on whatever player I happen to have handy (computer, 10 year old car CD player, 1 month old portable player, etc.). I can only use one at a time, so why this be difficult?
Make fair use of an excerpt from a song or movie and not have myself sued unto the seventh generation. Happy Birthday, indeed.
Know that future generations will be able to freely explore their history, just as we can freely explore our history, freely access and study works of the past, both great and mundane.
For #1, my alternatives are to download copies of questionable quality from sites of questionable morality, downloading itself being an act of questionable legality, or to go without. Some choice. Thanks Hobson.
For #2 and #3, well, since I happen to use Linux, I have an easier time obtaining and using the tools necessary to allow me to exercise my legal rights (in Canada, backup copies are, AFAIK but IANAL, legal), but why should I have to go through extraordinarily painful hoops to do so?
And my poor Mom doesn't stand a chance of understanding those hoops. And she lives on Windows, so they're orders of magnitude more painful.
For #4 and #5, well, forget it, there is nothing I can realistically do. The courts are far too sympathetic to corporate and estate interests: The presumption is that I am a criminal and a pirate so I must defend myself at outrageous expense, and hope, just hope that the courts get it right and order my costs to be paid. Sometime before me and my heirs are bankrupt, bankrupt because I presumed to exercise my rights.
The situation is so ass-backwards it is no longer even slightly amusing.
Lessig? I declare him to be my friend because he is a careful and balanced and critical thinker. Restore short term copyright? I'm good with that. It'll go to #5. And the thinking behind it will go to number #[1234] as well.
I will always be willing to support those that produce things of interest to me. But how do I know what they produce is of interest if I cannot sample?
Every song or movie I've downloaded and liked I've bought on disk. Despite the price. And for every such disk there are several I regret buying and wished I'd downloaded and test-listened first.
Imagine not being able to test drive a car before buying. Imagine a winery or brew-pub that did not provide tastes of their products.
Imagine industries that don't treat their customers like criminals.
Imagine computers and media players and songs and movies that don't treat fans like slaves.
Hyperbole? No.
I want to support artists whose work interests me.
I don't want to support cartels of lawyers and megalomaniac political and c
If you want to be protected by the patent terms of Open Source licenses... you need to be properly identified. Otherwise, you may have a hard time proving... you were "Blue Salad".
And on the flip side, if someone does go after "Blue Salad", they will subpoena ISP records, email provider records, and other evidence, and build an argument quite likely to convince a judge that you are, in fact, "Blue Salad". If there is real money involved, a pseudonym will not protect you.
My conclusion? For "patent protection", a pseudonym has no real value....
As an aside, I use my real name - Peter Whittaker - on almost all sites now because a) I'm proud of what I do, and b) as a consultant, my name is my brand. Why did I choose a pseudonym in the first place? Laziness and cheap spam protection: I wanted a single nickname to use on multiple sites, something I could throw away without regret if spam became a problem. Ironically, I never received much spam on the pseudonym@myisp.tld addresses, but did on a few of the first.last@myreallybadfirstisp.tld addresses./. is pretty much the only place I use a pseudonym anymore. As soon as/. supports it, I will change my nickname here.
Took me a minute to decide whether to mod or reply....
advances in computing power are always going to result in security schemes being broken
Not quite: No matter how powerful computers get, RSA, e.g., will not be broken, we will simply need larger keys. In other words, RSA has no fundamental cryptographic weaknesses, i.e., is not subject to any known cryptanalytic attack.
Like all modern cryptographic algorithms, like AES, like the SHA2 family (last time I checked), like CAST5, etc., RSA is subject only to brute force attacks. This is known and cannot be prevented. Since it is known, we know to use key sizes that are expected to be good for many years, even in the advent of ridiculous advances that greatly outpace Moore's Law.
The difference in the WEP case was that the scheme itself had fundamental cryptographic weaknesses. WPA's TKIP also has fundamental weaknesses. Certainly in the case of WEP and likely in the case of WPA/TKIP, the weakness required a certain level of computing power to exploit, and we could argue whether we reached that level of computing sooner than expected, but the weaknesses were known from the outset and, sadly, not field patchable.
(IMHO we - the security oriented tin foil hat wearing geek crowd - expected that level to be reached far sooner than it was, while they - the public, PHBs, etc. - believed it could never happen. Mas o menos.)
To be fair, you did mention "advances in research" as eventually resulting in all weaknesses, but being pedantic in this case is important:
Algorithm design is really tough and good algorithms are always proofed against all known attacks, so that brute force is the only way to break 'em.
Big cryptanalytic breakthroughs - really, fundamental breakthroughs in mathematics, e.g., analytic prime prediction, engineering, e.g., practical quantum computing, and physics, e.g., time travel, teleportation and subspace communication - are rare, relatively "generational" events, and impossible to plan for, predict, or mitigate.
Threat-risk assessment and security decision making is always about identifying the known and the likely and mitigating those. For a decision maker, be they an executive planning for the protection of an enterprise network or a homeowner keeping their WiFi LAN safe, lumping together the predictable and the science fictive is less than useless, it's distracting and potentially misleading.
We know - based on current physics and math - how long specific key sizes will be good for. We then choose keys that are orders of magnitude bigger and ensure that our schemes - our algorithms - can easily be configured to use larger keys when the time comes and we likewise ensure that our schemes have been publicly reviewed by expert cryptanalysts.
And then we're good for a good long time. Regardless of what happens to computing power.
I have mod-points, but I'll be kind and respond instead. Compare the user IDs of the two posts. He was trying to give an explanation to brain-dead moderators. He didn't communicate this very well, but your over-your-head style response was entirely inaccurate. It was an easy mistake to make.
Yeah, about that.
Is that not what meta-moderation is for?
Is it not like a joke, that when you have to explain it, or point out that it was a joke, there is no more joke?
Dude, the OP even bothered to enclose their comments in sarcasm tags.
When we start having to add comments to protect comments from moderators, we really have jumped the shark-infested cupcakes.
And, yes, I will be modded down as off topic. So what? Deal with it.
The last thing we need is a flurry of posts and mods aimed at protecting posts from the overly zealous and the large-integered.
Not only was it not an SSO solution, it predated Erlang's open-source release by several years and pre-commercial 3G by several more. It was based on a rather bizarre architectural decision that can be interpreted as sensible back in the days when:
There was still a lot of 16 bit Windows running around (amok?). Remember that? One of the main reasons "L"DAP exists, after all: If we were to create X.500 today, we might all be using DAP, since we'd not notice how heavyweight all of that ASN.1 processing is - after all, we can run Gnome and OO.o successfully!:-> (Hey, I'm running Gnome and OO.o on a 700 Mhz PIII - I'm kind of cheap - that blows the doors off any Intel-based computer I had at my disposal when I was reading that code......which is why I did most of my work under SunOS).
We all thought opening connections was slow and expensive, so we did it rarely: Open a connection, keep it open forever. Funnily enough, we moved to the more modern - but still far from common wisdom (SSL wasn't quite invented, though it would happen soon enough, HTTP was still 1.0, most servers still did one accept() then forked for every incoming connection) - open-request-response-close model in fairly short order 'cause of a performance bottleneck in the server that translated LDAP to DAP and made the connection to the directory (and that extracted PKI messages and sent those to the CA).
Doing it again just a few years closer to the bubble-burst, a) that code would never have existed, since the need to embed PKI messages in LDAP had disappeared, and b) zippy performance could have been sacrificed for more maintainable code, since all of the boxes and OSes were so much faster to begin with.
As for comments or other documentation, well, it's been my experience that good coders who can write well are rare, and brilliant hackers who can write at all well are very rare indeed. There's a reason literate programming is confined to a relatively small community: Most of us just aren't wired that way.
Me? Great writer (/. posts aside:->), adequate coder. Most of my code is, er, was, fabulously well commented and bullet-proofed in the extreme, but slowly produced and pedestrian in function.
Guess that's why I became a system architect, then a PHB, and eventually a consultant!
All kidding aside, WTF/minute is a deceptive metric.
I remember poring over about 30 lines of C for about two plus days with a WTF/minute ratio in the hundreds or thousands. And I knew what the code was supposed to do! It wasn't that I didn't understand it, I didn't understand why the guy who wrote it, a brilliant, brilliant hacker, wrote it the way he did.
Over two days of following the nested ifs, the gotos (no STL, no exception handling, the gotos made perfect sense), the logic, then BAM!
"Wow, that's fast!"
It was the most difficult-to-read code I'd ever read - and it was brilliantly brilliantly fast. (It was a network proxy involving PKI-related messages embedded in LDAP, all based on ASN.1 - all speed improvements were important, his were amazing.)
Most of the time, high WTF/minute is a good indication that the coder should never, ever have been allowed near a keyboard. Live an awful lot of Java.
But every now and again, high WTF/minute is a sign of absolute genius. Like a lot of really cool Haskell code. Or wicked perl.
Hmm, perhaps it's not WTF/minute that we need to consider, but its first order derivative. WTF/minute that peaks then declines to zero suggests genius. WTF/minute that remains constant suggests a bad day or a lot of PHB pressure. WTF/minute that increases without bound suggests brain-damage and a potential career in sales.
I remember hearing about a scheme that the US / UK axis used... to wiretap its own citizens.... the British eavesdropped on Americans' calls, and the Americans eavesdropped on Britons' calls, and then the two intelligence agencies simply compared notes
It's called ECHELON and its more than US-UK: It's the Anglic-5 (US, UK, Canada, Australia, New Zealand).
With Canada and Australia in the mix, a significant part of the globe is covered. And with all five countries in the mix, it's easy to imagine that perhaps one government would pass on information about persons of interest to any of the other four.
Oh, I suppose I need a mandatory/.ism:
...a scheme that the US / UK axis used to perpetrate...
In the first paragraph, the author acknowledges that the scope of the article does not include the changes between GPLv2 and v3.
? When you do RTFA, note the 6th and 7th paragraphs, from which I quote:
Under prior versions of the GPL, it was generally accepted that open source and proprietary software could peacefully coexist.... Under the new version of the GPL, the proprietary characteristics of software that step into the ring with open source software are knocked out.... Changes in the GPL impose other limits on the ability to leverage a proprietary position when open source is involved. Under the new version of the GPL....
Clueless post, more like.
Do I disagree or agree with the article? Doesn't matter. Though I really do like the closing paragraph:
With the new GPL in place, free software advocates seem willing and able to take action. You should make sure that the use of open source software is ready for the challenge.
(Unless they really meant to write Team Members' Celebration?)
Let's just hope there are no misplaced apostrophes in any of the wee beastie's code. Especially in the firmware update upload controller. That would be delightfully ironic....
Slashdot Mirror
Because either the 'i' should have been capitalized since "hardware" was followed by a period, or the period following "hardware" should have been a comma.
Since neither construction was used, the paragraph as written did not follow the conventional rules of grammar, therefore, the sic was required.
I also could have written "[hardware, i.e.,]", but that wouldn't have led to so many fruitful side discussions.
Remove the [sic]
See my previous comment: Since the immediately preceding token was a period, the previous statement was contained in a completed sentence. Conventionally, this requires that the first character of the next statement be capitalized, hence the need to write either "hardware, i.e." or "hardware. I.e.". Either choice would have removed the need for the sic.
...why does the summary [sic] i.e
Because the 'i' should have been capitalized since it was the beginning of a new sentence. Had Kolivas written "hardware, i.e." there would be no sic.
technically yeast is an animal
Uh, no: Technically yeast is a fungi and fungi are not animals. Nor are they plants. I invite you to do your research on biological classification, kingdoms, domains, animalia, fungi, plantae, etc.
Perhaps I am too much of a fan boy for my own country, but one Canadian site? And it's Baddeck?
Am I the only dinosaur-loving geek wondering why Drumheller isn't on the list?
The only paleontology-loving geek wondering at the omission of the Burgess Shale?
The only astronomy-loving geek wondering the exclusion of DRAO?
The only communications-loving geek perplexed at leaving out Signal Hill?
And these are only the ones right off the top of my head! Imagine what a little detailed research would uncover!
Use Case diagrams are UML
Excellent point - as are all of your "quibbles" (which I think you use to mean "pithy and accurate observation" - at least that's the sense I get from your post :->).
I poorly expressed the point I was trying to make when I wrote "no UML". I meant something more along the lines of "no jargon", no specialized terminology or diagrams that are unfamiliar to a non-technical audience. For example, "actors" and "agents" have specific meanings in various contexts, and while developers and architects know which context is which, most customers are going to think "Angelina Jolie" and "Swifty Lazar". And educating them on your terminology may well be counter-productive. Same thing with swim lanes, fish tails, entity-relationship diagrams, etc.
They all have their place, absolutely. And in a relatively larger organization with relatively more mature processes, architects and designers would use these, and someone else (marketing? project management? product management?) would translate these to language and format suitable for customers. (As an aside, which will become quite relevant momentarily, one role of these specialized tools and jargons is to convey meaning accurately and precisely to others who lack context, for reasons of time or space or both.)
My general inclination is that if you have a smaller organization and are just starting on implementing processes, it's best to just work with the customer presentables - you don't have the cycles or resources to do both, and you need the customer-facing stuff. The danger is that a lack of precision in your designs may lead to implementation errors. Or worse, customer acceptance problems.
Hence the "checkpoint and repeat" development cycle (involving the customer if it makes sense).
But if your organization is relatively small, you gain the benefit of context and conversation: You are not capturing design for later use by people who may not even have been hired yet, but for immediate use by a team of people who are likely all living this project (and possibly nothing else).
One of the big tricks of management is figuring out which organization you are, noticing when you are changing from one to the other, and adding process maturity at the right time (read: Just early enough, and never too late).
That's a big trick. If you can pull that off repeatedly, you have a solid future ahead of you.
This is one of the first posts I've ever wanted to mod to +6.
Quick, let's grab the slashcode and make it go to 11!
Of course, that will mean converting it to use base 5, but that might be cool. Today would be the 43rd day of the 4th month of the 31014th year, for example.
Seriously, thanks - I've got a little glow of slashpride right now!
Mod parent up. With all due respect to other posters, sending the submitter to ITIL is overkill. Talk about drinking from the firehose.
I use to run a number of development teams in a systems integration and custom development shop: We took our employer's base products and toolkits and integrated them into customer environments. We did a lot of "1.0's" - typical projects were 2 to 6 weeks in length and if we ever saw them again, we lost money. We could afford one or two moderate bugs (sev 3 - functionality impaired); more than that, we lost money. We could not afford major bugs (sev 1 - all is borked; sev 2 - most is borked). And given the tight timelines, we had to be very sure that what we were developing was what the customer asked for and what the customer asked for was what the customer wanted.
We almost always made money and our customers were almost always very satisfied. We very rarely lost money, and it was usually on strategic projects (spend integration money to make more license money).
Here's what we did:
Handling exceptions. If at any point things start to drift out of alignment, stop. Figure it out. If the problem was the high-level design, go back to the customer. Otherwise, it's an internal issue you have to identify and correct.
VIP: Acceptance test plan. Having the acceptance test plan signed off by the customer is crucial. If they sign it off and everyone codes to it and it aligns with the high-level design and the deliverable passes acceptance, then you are done.
One thing I've left out: Change requests. They are the bane of every project under development. You need to dig in your heels and manage them properly. Work collaboratively with the
the above is simply not correct. Putting aside issues of writing style, quality, completeness, etc., along with the abomination called info pages, manpages ARE documentation
You are putting aside things that cannot be put aside. Far too may Linux man pages are brief pointers to the info info, and far too often the info pages merely rehash the inadequate content of the man pages.
To qualify as documentation, a man page must include sufficient detail to act as a reference, not merely a command line summary.
UNIX man pages were documentation - and were how I learned UNIX, back in the day. Generally speaking, the Linux user is better off with web pages than with man pages - too many Linux man pages don't cut it.
Are you lawyer? If not, stop offering legal advice. I'm not a lawyer either, so I'll just paraphrase what my lawyer told me two weeks ago: "Sure, an NDA is a good step - if it can be enforced." If you are a lawyer, please cite case law, etc., that backs up this "magic NDA" view.
An NDA is not a magic shield that will protect your ideas. At best, it is one tool among many. At worst, it is fool's security blanket.
Another tool is the provisional patent.
And another is meticulous documentation - document every meeting, every email, etc. I make some people sign NDAs - for others, I rely on the fact that I can point to a body of evidence - correspondence, journals, etc. - that show that the ideas were mine. It depends on the person, the situation, the likelihood they will sign - if you ask someone for advice, why would they sign an NDA? What, exactly, do they get out of it?
Of course we have a 29 to 1 advantage in baseball teams and all of those guys use steroids so they could be pretty tough to beat in a fight
You neglect our fifth column: 24 hockey teams, most with Canadian captains and ~50% Canadian players. I'm sure we'll be able to co-opt the Europeans as well....
The hockey players are in full body armour, with deadly weapons in their hands and on their feet. So I'm pretty sure our fifth column hockey players will take out your drug addled club wielders (hint: Use AL pitchers as fodder, since they have yet to master the club).
Your only hope is that your guys in half body armour can stay in the fight for more than a single play.
And don't even think about enlisting basketball players - unless it's for the comic relief of a slap fight among the freakishly tall....
IIRC, a general purpose CPU has a small data cache and a large instruction cache, coz you can never be 100% sure which instruction is likely to be executed next. PS3s have large data caches and small instruction caches, because they spend much of their time executing a small number of instructions over a large set of data, that is, graphics rendering.
If you are doing any sort of mathematical simulation, you can likely express your numerical methods in a relatively small set of instructions. And you are likely going to have hoards and scads and barrels of data.
Machines like the PS3 are perfectly suited to number crunching. If only there were some way to kit them into a Beowulf cluster....
Again, IIRC, this was the original motivation for porting Linux to the PS2 before the official kit came out: Because a cluster of PS2s running Linux made for a far faster number cruncher than anything else available for a comparable price (or a price within an order or two of magnitude).
As for writing and optimizing code, well, let's just say you made my eyes bug out with that one. If you are doing any serious supercomputing, you are ALWAYS writing and optimizing code: The point is to get the fastest possible execution so you can crunch the greatest amount of data possible and get the best possible results from your work.
In serious number crunching, the effort spent coding and optimizing is almost always going to pay off.
Whoa, slow down there, bucko - I think you might confusing rotation with projection.
Project those imaginary dollars onto the real axis and you'll get exactly what this post is worth!
Homework assignment: Using this reasoning, show the recent financial troubles could have been predicted using simple vector analysis. Bonus points from computing the cross-product of Al Greenspan and Warren Buffet.
Me too!
The 3 I missed.... #7, thought it was much earlier; #10, knew it wasn't A, guessed one of the others; and #33.
33 is an interesting one. I chose "debt", though I knew it was wrong, but felt it was "more right" than any of the others. Deficit would have been 100% correct, no question. I dispute the correct answer, because it is open to interpretation. I took it to mean "is spending on me exactly what I pay in taxes", which is obviously correct only for a very few. If they'd stuck in "average", that would have been fine, and while I agree you could argue it was implied, well, when words are implied the result is almost always ambiguity.
Just look at the 2nd amendment and the all the ruckus arising from its ambiguous phrasing!
He is not our ally in ensuring we can get whatever media we want whenever we want for no cost.
I beg your pardon? Why are you putting words in our mouths?
I don't want whatever media whenever at no cost. I want to buy a copy of a song or movie at a reasonable cost (pennies on the download, dimes for a hardcopy) and listen to that copy on my computer, in my car, in my house, while walking the dog, whatever, and make a backup copy just in case. And I want those things to be easy to do. Easy for me. And easy for my 75 year old Mother when she buys something.
If I want to watch a movie again and again (which is the only reason I buy 'em in the first place), then when I stick the farging disk in the farging player I want it to farging play, goldurnit! I don't want to have to watch the same warning over and over and over and over and over and OMG not again over....
And I want all works to eventually get where they should be: The public domain. Perpetual copyrights and excessively long copyrights and corporate coddling are social evils.
As it is now, I cannot
For #1, my alternatives are to download copies of questionable quality from sites of questionable morality, downloading itself being an act of questionable legality, or to go without. Some choice. Thanks Hobson.
For #2 and #3, well, since I happen to use Linux, I have an easier time obtaining and using the tools necessary to allow me to exercise my legal rights (in Canada, backup copies are, AFAIK but IANAL, legal), but why should I have to go through extraordinarily painful hoops to do so?
And my poor Mom doesn't stand a chance of understanding those hoops. And she lives on Windows, so they're orders of magnitude more painful.
For #4 and #5, well, forget it, there is nothing I can realistically do. The courts are far too sympathetic to corporate and estate interests: The presumption is that I am a criminal and a pirate so I must defend myself at outrageous expense, and hope, just hope that the courts get it right and order my costs to be paid. Sometime before me and my heirs are bankrupt, bankrupt because I presumed to exercise my rights.
The situation is so ass-backwards it is no longer even slightly amusing.
Lessig? I declare him to be my friend because he is a careful and balanced and critical thinker. Restore short term copyright? I'm good with that. It'll go to #5. And the thinking behind it will go to number #[1234] as well.
I will always be willing to support those that produce things of interest to me. But how do I know what they produce is of interest if I cannot sample?
Every song or movie I've downloaded and liked I've bought on disk. Despite the price. And for every such disk there are several I regret buying and wished I'd downloaded and test-listened first.
Imagine not being able to test drive a car before buying. Imagine a winery or brew-pub that did not provide tastes of their products.
Imagine industries that don't treat their customers like criminals.
Imagine computers and media players and songs and movies that don't treat fans like slaves.
Hyperbole? No.
I want to support artists whose work interests me.
I don't want to support cartels of lawyers and megalomaniac political and c
If you want to be protected by the patent terms of Open Source licenses... you need to be properly identified. Otherwise, you may have a hard time proving... you were "Blue Salad".
And on the flip side, if someone does go after "Blue Salad", they will subpoena ISP records, email provider records, and other evidence, and build an argument quite likely to convince a judge that you are, in fact, "Blue Salad". If there is real money involved, a pseudonym will not protect you.
My conclusion? For "patent protection", a pseudonym has no real value....
As an aside, I use my real name - Peter Whittaker - on almost all sites now because a) I'm proud of what I do, and b) as a consultant, my name is my brand. Why did I choose a pseudonym in the first place? Laziness and cheap spam protection: I wanted a single nickname to use on multiple sites, something I could throw away without regret if spam became a problem. Ironically, I never received much spam on the pseudonym@myisp.tld addresses, but did on a few of the first.last@myreallybadfirstisp.tld addresses. /. is pretty much the only place I use a pseudonym anymore. As soon as /. supports it, I will change my nickname here.
Took me a minute to decide whether to mod or reply....
advances in computing power are always going to result in security schemes being broken
Not quite: No matter how powerful computers get, RSA, e.g., will not be broken, we will simply need larger keys. In other words, RSA has no fundamental cryptographic weaknesses, i.e., is not subject to any known cryptanalytic attack.
Like all modern cryptographic algorithms, like AES, like the SHA2 family (last time I checked), like CAST5, etc., RSA is subject only to brute force attacks. This is known and cannot be prevented. Since it is known, we know to use key sizes that are expected to be good for many years, even in the advent of ridiculous advances that greatly outpace Moore's Law.
The difference in the WEP case was that the scheme itself had fundamental cryptographic weaknesses. WPA's TKIP also has fundamental weaknesses. Certainly in the case of WEP and likely in the case of WPA/TKIP, the weakness required a certain level of computing power to exploit, and we could argue whether we reached that level of computing sooner than expected, but the weaknesses were known from the outset and, sadly, not field patchable.
(IMHO we - the security oriented tin foil hat wearing geek crowd - expected that level to be reached far sooner than it was, while they - the public, PHBs, etc. - believed it could never happen. Mas o menos.)
To be fair, you did mention "advances in research" as eventually resulting in all weaknesses, but being pedantic in this case is important:
We know - based on current physics and math - how long specific key sizes will be good for. We then choose keys that are orders of magnitude bigger and ensure that our schemes - our algorithms - can easily be configured to use larger keys when the time comes and we likewise ensure that our schemes have been publicly reviewed by expert cryptanalysts.
And then we're good for a good long time. Regardless of what happens to computing power.
ryanvm (247662) wrote the Slashdot crowd
Dude, you may a 6 digit UID, but it's still relatively low.
Doesn't that make you part of the /. crowd?
I'm tired of hearing of us spreading this lame FUD scenario
There, fixed that for ya!
Yeah, about that.
Is that not what meta-moderation is for?
Is it not like a joke, that when you have to explain it, or point out that it was a joke, there is no more joke?
Dude, the OP even bothered to enclose their comments in sarcasm tags.
When we start having to add comments to protect comments from moderators, we really have jumped the shark-infested cupcakes.
And, yes, I will be modded down as off topic. So what? Deal with it.
The last thing we need is a flurry of posts and mods aimed at protecting posts from the overly zealous and the large-integered.
Buh.
WHO0O0O0O0O0O0SH!
Not only was it not an SSO solution, it predated Erlang's open-source release by several years and pre-commercial 3G by several more. It was based on a rather bizarre architectural decision that can be interpreted as sensible back in the days when:
Doing it again just a few years closer to the bubble-burst, a) that code would never have existed, since the need to embed PKI messages in LDAP had disappeared, and b) zippy performance could have been sacrificed for more maintainable code, since all of the boxes and OSes were so much faster to begin with.
As for comments or other documentation, well, it's been my experience that good coders who can write well are rare, and brilliant hackers who can write at all well are very rare indeed. There's a reason literate programming is confined to a relatively small community: Most of us just aren't wired that way.
Me? Great writer (/. posts aside :->), adequate coder. Most of my code is, er, was, fabulously well commented and bullet-proofed in the extreme, but slowly produced and pedestrian in function.
Guess that's why I became a system architect, then a PHB, and eventually a consultant!
Well, that and the layoffs. Yay, bubble.
hot damn. a new and useful [SI] unit. thanks
All kidding aside, WTF/minute is a deceptive metric.
I remember poring over about 30 lines of C for about two plus days with a WTF/minute ratio in the hundreds or thousands. And I knew what the code was supposed to do! It wasn't that I didn't understand it, I didn't understand why the guy who wrote it, a brilliant, brilliant hacker, wrote it the way he did.
Over two days of following the nested ifs, the gotos (no STL, no exception handling, the gotos made perfect sense), the logic, then BAM!
"Wow, that's fast!"
It was the most difficult-to-read code I'd ever read - and it was brilliantly brilliantly fast. (It was a network proxy involving PKI-related messages embedded in LDAP, all based on ASN.1 - all speed improvements were important, his were amazing.)
Most of the time, high WTF/minute is a good indication that the coder should never, ever have been allowed near a keyboard. Live an awful lot of Java.
But every now and again, high WTF/minute is a sign of absolute genius. Like a lot of really cool Haskell code. Or wicked perl.
Hmm, perhaps it's not WTF/minute that we need to consider, but its first order derivative. WTF/minute that peaks then declines to zero suggests genius. WTF/minute that remains constant suggests a bad day or a lot of PHB pressure. WTF/minute that increases without bound suggests brain-damage and a potential career in sales.
It's called ECHELON and its more than US-UK: It's the Anglic-5 (US, UK, Canada, Australia, New Zealand).
With Canada and Australia in the mix, a significant part of the globe is covered. And with all five countries in the mix, it's easy to imagine that perhaps one government would pass on information about persons of interest to any of the other four.
Oh, I suppose I need a mandatory /.ism:
...a scheme that the US / UK axis perpetrate...
There, fixed that for ya!
Did you? Then how do you justify writing
? When you do RTFA, note the 6th and 7th paragraphs, from which I quote:
Clueless post, more like.
Do I disagree or agree with the article? Doesn't matter. Though I really do like the closing paragraph:
There is a repeated error on http://www.jpl.nasa.gov/news/phoenix/images.php: The caption used for many images should read Team Members Celebrate and not Team Members' Celebrate
(Unless they really meant to write Team Members' Celebration?)
Let's just hope there are no misplaced apostrophes in any of the wee beastie's code. Especially in the firmware update upload controller. That would be delightfully ironic....