The TIA is a rather high-profile project that needs some access to some pretty heavily watched data sources. You could, in theory, still do all of it in the black, but you're going to need a ton of people to be in on it. And unlike Iran-Contra, this time those people are in country.
That's what it would be, after all... a whole new Iran-Contra scandal, but with much more clear (il)legalities. And while Ashcroft would certainly be first in line, it's questionable that Bush would be able to insulate himself from an illegally funded project that he supported.
It's much more likely that it'll die and be resurrected again in a couple years under a different name.
But what about sub vs sub warfare? That's what the subs are there for in the first place really... you certainly don't need attack subs in a carrier group to sink surface ships - there's 5 ways to Sunday to do that with the rest of the group.
It's the notation used by ALL standardized languages. If your particular language doesn't use it, it's because it's not a standardized language.
Part of the standardization process involves making sure changes are not made to the language too fast. Once a standard is agreed upon no official discussion can be started about the next standard for 5 years. A vote cannot be taken for 10 years.
The latest version of C is officially C99. But you don't refer to it as that... just as C. Whether or not your compiler is C99 compliant is only discernable by poking around the docs.
Better be sure you learn something about carrier battle groups before posting tripe like this.
A standard CBG contains two 688 class attack subs. Yeah, the subs that are easier to detect by finding the hole in the ocean rather than trying to actually find sound traces. No, we don't need two new ones - the Constellation is being retired as the RR is being commissioned, so her battle group gets transferred.
On top of the two 688's, you also have ASW (anti-submarine warfare for those short on TLAs) equipped frigates and destroyers in the CBG. Plus the bevy of helicopters and ASW airplanes in the CBG -- and don't forget that the frigates, destroyers, and cruisers can all have their own helicopters in addition to those on the carrier.
As for missile threats -- another good luck. Presuming you can get close enough to fire upon the carrier (an Exocet has a range of ~45 miles, while the F-14 launched AIM-54 Phoenix has a range exceeding 100 miles and the SM-2 surface-to-air missiles have a 100 mile range), the AEGIS-equipped cruisers and destroyers and the carrier itself have point defense phalanx guns which can handily take out multiple missiles.
Yes, a carrier can be taken out. But not easily. You'd need to launch multiple waves of missiles with the understanding that you still have a low chance of success with a high chance of all operators being taken out.
The slightly easier target is not the carrier, but the supply ship. It's generally located well away from the carrier and contains fuel and ammunition for the CBG. Remember, only the carrier and the subs are nuclear powered (there are some conventionally powered carriers still), and all of the aircraft run on jet fuel as well. The big advantage to eliminating it is that you'll cripple the entire battle group, and it's a much easier target than the carrier itself. Easier being a relative term of course.
My wife actually preferred having a slightly hard to type name in EQ... when you need to get a buff and you have 5 clerics to chose from, do you type "Magdylena" (her cleric) or "Iena" (another guild cleric)?
She always liked not being the buff bitch.
On the other hand, my enchanter's name (Llarn) was probably the easiest to type. Which is probably why I got driven nutty by buff requests while trying to help herd cats (aka helping to manage an uber guild).
No, neither of us play anymore. So happy to be free of that addiction.
So should that tell go to azby, azbysyap, or Azbywnwefcxxyxx-III?
You can abbreviate commands... abbreviating names is hopeless. Although a good game will allow for aliases.
In Quake, UT, BF1942, and other FPS's I'm always Zathrus. In EQ I played Tularin (Ranger) and Llarn (Enchanter). The former made up from the top of my head, the latter was an attempt to do the same, but it's actually the name of a very early Rogue variant (which last time I searched I couldn't find).
The only real plus I can see would be DirectX. That said, Linux has OpenGL, OpenAL, SDL, Allego, SVGAlib, and anything else you want.
Anything else, except DirectX that is.
Now that we've gotten that out of the way, count how many modern games are written for OpenGL, OpenAL, SDL, Allego, or SVGAlib. Now count how many are written for DirectX.
Now if you want people to port to your platform, which is the safer bet?
Sure, you can (and probably will) release your own SDK, but you still have to deal with reality. Game makers have 4 primary platforms right now - PCs, PS2, Xbox, and Gamecube. Xbox gets to leverage PC development since they're not too far off from one another -- you need to change things certainly, but the core engine can remain the same. Mostly. If you're creating a new platform then you may as well either leverage off one of the established platforms, or have one helluva lot of capital behind you to create a new one and lure developers over. Since you'll be going up against Microsoft, Sony, and Nintendo, I really hope you have a lot of capital.
Since two of the four platforms are completely and utterly closed - Nintendo and PS2 - you only have one option to leverage. DirectX. Done right you can actually do better leveraging than the Xbox... although it's not sounding like they're doing this.
Oh, and before you flame me as a Windows bigot, I'm not. Yeah, I use it. I also use Redhat and code for Unix. I prefer Unix. But that doesn't mean I put blinders on and whine about how the world should work instead of understanding how it actually does.
Uh... I don't think you quite get it. Putting your docs in CVS is all well and good (and smart). We do. But that doesn't help a bit with what the poster wants, since CVS doesn't help show changes with binary files. And even if it did, what good is that going to be to you? Heck, even if you used OO.org and stored the doc as uncompressed XML it's not going to help, because you don't want to see the raw data -- you want to see the document.
More importantly, you want to see the document with revisions so that you can accept or reject suggested changes on a per change basis.
Word does this quite well. We've used it extensively during the creation of requirements and specification docs. For operations stuff we use a Twiki, which works better for that. Right tool, right job.
I haven't used OO.org's track changes tools, so I can't comment on them. Word's tools work quite well though.
Why? What's the point? It doesn't have 3D capabilities (at least none worth even mentioning at only 8 MB), and 2D video is old hat nowadays. You can get any number of cards with fully accelerated 2D drivers under Linux. The issue is 3D drivers... and then it's only an issue if you want open source drivers that actually perform to the cards capabilities.
I think you have a complete and total lack of understanding about video cards based on your 8MB vs 32MB comment. You realize that 1600x1200 32-bit 2D video uses only 5.7 MB of memory? There are higher resolutions, but they're rarely used. The only need for more memory is texture buffering and z buffering, which are both purely in the realm of 3D graphics. More memory does not have any impact whatsoever on 2D graphics. In fact, most 3D cards are relatively unconcerned about their 2D speeds because it's all "fast enough" nowadays (and yes, I'm old enough to remember when 2D speed was a key measurement -- and remember getting my first card (a Number9 Imagine128, won at Comdex) that could actually scroll text in a window faster than it could full screen).
Heh. Well, I'm quite literally working on this stuff when not avoiding doing work by reading/., so it's quite fresh.:)
And yes, it is still easier than dealing with Perl-guts... the docs for that (last time I glanced at them, which was years ago) were quite horrid, and I've never tried it myself anyway. Still having issues at the moment (core dump upon import), but investigating the causes and solutions. Things are moving.
The re module does have a sub() function, but that's fairly well documented.
Yeah, but the bit of docs I quoted are from the re.sub() documentation! Like I said, really annoying when it references you to something that doesn't appear to exist.
I just looked back at the tutorial and found the section on the % operator -- which does exactly what I thought it did. I suspected that it wasn't tied to print, and it's definitely a nifty and good way to format things. Thanks for the heads up on where to find it.
As for books, one of my coworkers has the Python 2.1 Bible, which had far better info on some of the aspects of extending Python. It's at least gotten me to the core dump stage:). All we're really looking to do with Python is a load test tool and some Big Brother monitoring scripts (the latter of which is needing the extention -- that or rewrite a thousand+ lines of C++ for python and then maintain both whenever something changes) so it's not entering into our development in a big way. Yet. But it's unlikely that we'll use any other advanced scripting language at this point, since increasing the number of languages utilized (currently C++, shell script, SQL, and Python, with Java being used in another part of the project) just makes maintainence more and more difficult.
Doing Perl w/o a book is possible... but doing it without a book or the man pages/online versions of same would be a PITA. I don't actually own the Camel or Llama... the man pages are perfectly good for me. I also don't read other people's perl script though:)
It's going to make waves, but it's still pretty new tech. I work for a company in the industry (no, you've never heard of us unless you're an owner of a freight hauler or line shipper, or maybe one of their data entry people) and it's being looked at now. I suspect the big guys (like UPS and FedEx) are considering it as well.
One thing to consider is that most of the transport industry is deeply low tech. Most handling and tracking is still done with paper, faxes, and telephone calls. AFAIK, we're the first company to even offer end-to-end electronic invoicing in the industry - up until now it's been done with snail mail. And this is a huge, multi-billion dollar industry -- even after you exclude UPS, FedEx, and Airborne. It ranges all the way from shipping aircraft engines for Boeing jetliners to shipping the fridge you bought from the local big box store to your house. And nearly all of it is still done on paper.
I'd be willing to guess that nearly none of it is from switching to Linux... yes, the OS is free. That's nice. The support is not, and anyone who thinks that the Japanese government is going to run their payroll system without support on every single bit of the system is living in some alternate universe. It may be that the support costs for Linux and the other software (database, payroll, etc) are dramatically lower than it was for the old mainframe systems though.
Additionally, unless they're deploying Linux on the exact same hardware that their old system was running on, you can't credit Linux with the operating cost savings
Well, credit Linux, no... but that may very well be a substantial portion of it. Imagine the cost savings of moving from a few ancient water-cooled mainframes to a modern AS/400 or eSeries server. The water and power savings will be immense.
Overall I'm sure you're correct - Linux is a side note here and not the primary cause of cost reduction.
Dang it, I meant to put in some concrete examples but apparantly forgot. Blergh.
First off, I'm using the Python 2.1 docs -- they may be outdated and the more recent 2.2 or 2.3 docs may be better, but 2.1 is what's installed on our development and production boxes, and we dislike changing those kinds of things unless we need to.
The C API docs stink. There's not a single complete example in the doc tree (on python.org) that I've found -- just snippets here and there. There are references that extending Python is very simple (and, indeed, it does appear to be now that I've found sufficient docs) and there's even tools to automate most of it. But nowhere are the actual tools referenced/linked to, there are calls used without explanation or links to explanation, and the docs suddenly shift between extending and embedding without adequate differentiation.
I dislike the break between the "Extending and Embedding" section and the "Python/C API" section. Yes, one's a tutorial and one's a reference, but the tutorial is thus missing vast amounts of info that are only present in the reference section. Bad.
I'm not real happy with the organization of the Global Module Index. There's a couple hundred default modules, and sometimes you have to go hunting through several different ones to find the desired function. The Library Reference is often lacking in reference as well -- for instance, section 4.2.4 (Regular Expression Objects) describes the re.sub() function which is "Identical to the sub() function, using the compiled pattern". That's nice. Where's the built-in sub() function? It's not in section 2.3 - Built-in functions. Nor is it a string.* function. I've looked in the places that made sense to me, and gave up, using string.replace() instead (which is what is appropriate for my usage, but I'm still wondering). I finally found some documentation on the print statement. In the "Language Reference" section (which makes sense... except that it's subtitled "for language lawyers"). And I'm still wondering about a 'print "bleh %s bleh" % (val)' construct I used... copied from elsewhere, since I can't figure out what the % is doing except by reference. I'm sure it's documented... and I'll eventually find it... but it's annoying right now.
By and large I suspect you're correct -- I'm used to the Perl docs and know where to find things. I'll eventually get used to the Python docs as well. But in the meantime I'm finding it annoying to learn. I should probably go out and pick up the O'Reilly Python book... I learned Perl from reading the Camel (1st ed) and hacking away at things. Doing much the same with Python, but the online docs are frustrating me at the moment due to a lack of global indexing (beyond site wide search which is vast overkill).
PhysicsGenius is a known troll... and it's amusing to see just how many moderators get caught by him. All of his posts have just enough in them to sound intelligent, but they're all very deeply wrong -- usually twisting the facts backwards (such as this one) or flying off into realms of thought usually reserved for the insane.
Maybe some moderators with a clue will beat the grandparent post down now.
On topic - I've known Perl for awhile and am starting to code in Python... the syntax is certainly cleaner, but the docs certainly aren't. To put it kindly, they suck. Yes, if I was sufficiently motivated then I could contribute instead of just bitching, but: A) I'm not, B) I don't know nearly enough Python yet to do it right. I find Perl's documentation to be layed out in a much more rational and useful structure. Shrug.
Since you then have to go back over the entire work, with a single person, to ensure consistancy between chapters (particularly for word choice, idiosynchracies, and word plays) -- still over a month. In fact, it's questionable that you'd save much time at all.
Why on earth was this modded up as insightful? It's not insightful, it's completely offtopic. It's gobbleygook that has nothing at all to do with the article.
Similar things have not been done -- Mapquest doesn't offer anything like this. Sat images don't give this information, and this isn't at all about "getting from Point A to the mall". Nor does it have anything to do with business or marketing, excepting that the entirety of our economy is now dependant upon this seemingly irrelevant infrastructure.
The point is that -- it maps out the infrastructure. Are you going to want to go to the mall if it has no power? Or maybe no inventory, because the power and data lines have been cut to the suppliers? Of course, that presumes you even have gas for the car -- those gas pumps won't do much without power. And while you can still move trucks on the freeway, the supply chain is now totally dependant on computer interaction to indicate when stations need more fuel. It used to be that the data flow was via sat, but it's now done through DSL for stations in major metro areas. Of course, it may be difficult to pay for the gas -- the ATMs won't be able to dispense cash without network access. Your credit cards won't work either - that whole network thing again.
No, you don't need to know the infrastructure. That's the whole point afterall. But other people do -- either for disaster planning (and I'm not talking terrorists here... tornados, earthquakes, floods, and other natural occurances can be enough of a problem), city planning, or other uses. And, yes, there are national security concerns here, but the answer isn't to bury the research -- it's to utilize the research. Use the maps to show where the points of vulnerability are and then diversify them. Build backups and redundancy into the system. Don't ostritch on the problem. No, it's not cheap. And in many cases it's not easy, particularly when faced with natural obstacles like rivers and mountains. But it's doable and necessary.
I would have thought, that the publishers would have learnt their lesson, and made sure that translations into the other languages where Harry Potter has a large fan base would be released on the same day as the english version, or failing that, not more than a month later.
Doing a top quality translation of a 700+ page novel takes more than a month. Even to a language relatively close to English such as German (and while I can't speak German, I did take several German classes in high school... they're sufficiently different to cause massive headaches).
Prior to it's distribution the 5th book was only read by 5 people, one of which was J.K. Rowling herself. They wanted to keep a tight lid on the contents, and they succeeded pretty well -- only in the couple days before release were any books leaked from the distribution chain. If you farm the book out for translations a month or so beforehand (if that's even possible, given how close some authors cut the delivery dates for publishing) then you may as well forget it -- you'll have full copies of the book wandering around within days of releasing it for translation.
That said, I'm rather surprised at how long the lead times are for the translated works... if the publishers are that concerned, then much more than 3 months is unacceptable. If it's a really difficult translation (say to an Oriental tongue or Basque) then 6 months may be understandable... but translating to Czech takes nearly 8 months? Please!
As it stands, SCO will have to prove that IBM broke its trade secret agreement, which is going to be a damned difficult thing for SCO to do. They're alleging copyright infringement as well but, and this is important, have yet to file a claim in court about any infringement whatsoever. Until they do so what exactly are you going to sue them for? Libel? Good bloody luck. You'd then be on the wrong side of the table -- you'd have to prove that their claims are false without ever seeing any of their documentation. Enjoy! You'll lose that case in a millionth of the amount of time the SCO/IBM case will take. If you even make it to day 2 in court I'll be amazed.
Here's the deal though -- since SCO is bringing the case against IBM they will have to disclose ALL relevant information on the case to IBM. And presumably to the public, unless they somehow get the record sealed (and SCO does not have the political might that AT&T had in the AT&T/Berkeley case). The claimant is not allowed to spring surprises on the defendant in the US court system -- the defendant, being presumed innocent, is privy to all the claims being brought against them as well as all evidence to support those claims. The same is not true in reverse -- IBM can bring out evidence to counter SCO without SCO's lawyers having ever seen it before (this, however, is generally considered bad form and frowned upon not only by the other lawyer, but also the judge -- judges don't like having their time wasted and any such evidence should be shared with the claimant in order to avoid having the case go to trial in the first place).
IBM may bring a countersuit against SCO, but in order to do so they'd have to show some substantive damages to their business model... not a very easy thing to do, particularly when you're the size that IBM is. It also complicates matters, and if IBM thinks they have a solid case they may not feel the need to bring a countersuit... easier just to shut them down quickly rather than turn an already long and complicated case into an even longer and more complicated case. Countersuits seem to be used most often when neither side has a particularly strong case.
It seems to me that some of the players in this game have much more knowledge then they admit openly.
Oh, so now you're going to convince everyone in the world to stop selling military hardware? You realize that the US is hardly the only military power selling its older technology overseas -- France, Britain, Russia, China, and pretty much every other military power does so as well. Oh, and you can't just get an agreement to not sell to the Middle East/SW Asia countries, since most of the arms deals are done through intermediaries.
Not to mention that a large number of arms are embargoed in that area anyway, at least to particular countries such as former Iraq, Iran, Syria, et. al. -- and yet they still buy them and get them through the inspections. No, I'm not talking WMD... I'm talking about things like the French tanks that Iraq acquired after the first Gulf war. I'm not blaming the French here, mind you, because I seriously doubt they intended to sell them to Iraq, but they still wound up there. International arms trade is hardly done above the board. (As it happens, I suspect France would have much rather not had their tanks show up in Iraq... since it showed how pathetically they fared against US tanks, and prior to that time there was a good bit of discussion about which would be better - the fast, light French armor or the slow, heavy US armor. The US armor had twice the range and one shot, one kill capability. The French tanks couldn't even close to fire, and if they did they didn't have the firepower to eliminate a US tank before being destroyed).
Of course, if you did magically shut down the arms trade in the middle east, it wouldn't stop the production of weapons. Most of the countries have factories for the manufacture of small arms -- it doesn't take that much. Israel designs and builds their own tanks as well, so it wouldn't even stop that. You'd cripple the air forces of all the countries, but since Israel has a vastly superior air force to start with it's not going to help the odds that much.
I don't think that's what he meant by a "standard library"
Then why did he explicitly mention the STL?
that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc
Oh, you mean all the OS specific stuff that is horrendously outdated rapidly or is so generic as to be devoid of features and richness? Yeah, shower me with that stuff.
STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
Uh... yes, it is a big whoop. If you don't think so, then might I recommend Pascal? You can even build your own string data type and manipulators!
Oh, btw, the STL does not contain hash tables. GNU's STL has them, but they're an extention to the STL, not part of the actual STL.
As for why it actually is a big deal - the STL is designed, first and foremost, for efficiency. When you ask for a vector you have guarantees about how it's implemented, how efficient certain operations are, and so forth. This is key to an efficient program, and particularly for embedded programming (which was a consideration for anything in the core C++ language or the STL). The same cannot be said for Java, C#, Perl, Python, etc.
I'm not recommending that you use C++ for everything... that's just silly. But for large programs that have to consider execution speed as well as development speed, it's one of the best bets out there right now.
Well, I rather disagree with him on this point... particularly regarding C++.
There is, indeed, a standard library for C++, one which is widely supported - STL. Is there a learning curve? Sure. And you're going to tell me that there isn't a learning curve for any other language, library, or whatever? Please.
I started at my current job a bit over 15 months ago. I knew only the basics of C++, and nothing at all about the STL (or even templates). It took me about a week to be comfortable using the STL, and I could read the code instantly -- there's nothing radical about it.
Are compile times long? They can be... particularly if you need to compile from scratch or change one of the base libraries used. But on modern hardware it's not a huge issue, and consider how much time you'll end up saving users because it's not an interpreted or pseudo-compiled language. Yeah, I like Perl and Python too, but they're not suitable to really large projects, particularly if you need them to scale very widely.
Doubt it. Odds are, the tags that were on the pants when you bought them were attached with and/or made of plastic. They were probably manufactured with machines containing rather large amounts of plastic, and were shipped in containers partially made of plastic.
my broom
Old broom then. Most of the newer brooms are made entirely of plastic -- yeah, they're the cheap ones. They work just fine too.
books on my shelf
Which probably had theft prevention tags in them which contained plastic.
virtually all the mail I get
What, you mean the magazines that have plastic wrappers, or any of the mail with a plastic clear window? And I've had an increasing number of junk mails that actually used plastic-ish envelopes.
my cat
As you noted, good odds it recently ate something plastic:) -- but even then it's litter is probably in a plastic container (unless it's an outdoor cat, in which case I really hope it isn't!), good chances that the food/water bowls are plastic, and really good odds that some of its toys are plastic (hell, our youngest cat's favorite toy is a plastic tie wrap).
Yeah, pushing it on some of those, but you know what the OP meant, and he's pretty much correct. There's very little chance that you can entirely avoid the use of plastic nowadays.
I'm utterly amazed that in the 14 replies thus far, nobody's given you the right answer.
If you want a true, original IBM PC keyboard then go here. They make the originals, complete with massive weight and key klacking, plus modified versions that have the Windows key, integrated mouse, college mascot/color inspired ones, quiet versions, etc... yes, they're pricy by modern day keyboard standards, but if you want a keyboard that will live somewhat longer than all of your descendants there's no other option.
I actually have two original IBM PS/2 keyboards, bought from used computer stores nearby... but the noise annoyed the hell out of my wife and I recently switched to a Memorex multimedia keyboard. It's really not all that bad, and every once in a great while I even remember to use some of the extra keys on it.
Slashdot Mirror
The TIA is a rather high-profile project that needs some access to some pretty heavily watched data sources. You could, in theory, still do all of it in the black, but you're going to need a ton of people to be in on it. And unlike Iran-Contra, this time those people are in country.
That's what it would be, after all... a whole new Iran-Contra scandal, but with much more clear (il)legalities. And while Ashcroft would certainly be first in line, it's questionable that Bush would be able to insulate himself from an illegally funded project that he supported.
It's much more likely that it'll die and be resurrected again in a couple years under a different name.
But thank you for the paranoia all the same.
But what about sub vs sub warfare? That's what the subs are there for in the first place really... you certainly don't need attack subs in a carrier group to sink surface ships - there's 5 ways to Sunday to do that with the rest of the group.
It's the notation used by ALL standardized languages. If your particular language doesn't use it, it's because it's not a standardized language.
Part of the standardization process involves making sure changes are not made to the language too fast. Once a standard is agreed upon no official discussion can be started about the next standard for 5 years. A vote cannot be taken for 10 years.
The latest version of C is officially C99. But you don't refer to it as that... just as C. Whether or not your compiler is C99 compliant is only discernable by poking around the docs.
Better be sure you learn something about carrier battle groups before posting tripe like this.
A standard CBG contains two 688 class attack subs. Yeah, the subs that are easier to detect by finding the hole in the ocean rather than trying to actually find sound traces. No, we don't need two new ones - the Constellation is being retired as the RR is being commissioned, so her battle group gets transferred.
On top of the two 688's, you also have ASW (anti-submarine warfare for those short on TLAs) equipped frigates and destroyers in the CBG. Plus the bevy of helicopters and ASW airplanes in the CBG -- and don't forget that the frigates, destroyers, and cruisers can all have their own helicopters in addition to those on the carrier.
As for missile threats -- another good luck. Presuming you can get close enough to fire upon the carrier (an Exocet has a range of ~45 miles, while the F-14 launched AIM-54 Phoenix has a range exceeding 100 miles and the SM-2 surface-to-air missiles have a 100 mile range), the AEGIS-equipped cruisers and destroyers and the carrier itself have point defense phalanx guns which can handily take out multiple missiles.
Yes, a carrier can be taken out. But not easily. You'd need to launch multiple waves of missiles with the understanding that you still have a low chance of success with a high chance of all operators being taken out.
The slightly easier target is not the carrier, but the supply ship. It's generally located well away from the carrier and contains fuel and ammunition for the CBG. Remember, only the carrier and the subs are nuclear powered (there are some conventionally powered carriers still), and all of the aircraft run on jet fuel as well. The big advantage to eliminating it is that you'll cripple the entire battle group, and it's a much easier target than the carrier itself. Easier being a relative term of course.
My wife actually preferred having a slightly hard to type name in EQ... when you need to get a buff and you have 5 clerics to chose from, do you type "Magdylena" (her cleric) or "Iena" (another guild cleric)?
She always liked not being the buff bitch.
On the other hand, my enchanter's name (Llarn) was probably the easiest to type. Which is probably why I got driven nutty by buff requests while trying to help herd cats (aka helping to manage an uber guild).
No, neither of us play anymore. So happy to be free of that addiction.
So should that tell go to azby, azbysyap, or Azbywnwefcxxyxx-III?
You can abbreviate commands... abbreviating names is hopeless. Although a good game will allow for aliases.
In Quake, UT, BF1942, and other FPS's I'm always Zathrus. In EQ I played Tularin (Ranger) and Llarn (Enchanter). The former made up from the top of my head, the latter was an attempt to do the same, but it's actually the name of a very early Rogue variant (which last time I searched I couldn't find).
The only real plus I can see would be DirectX. That said, Linux has OpenGL, OpenAL, SDL, Allego, SVGAlib, and anything else you want.
Anything else, except DirectX that is.
Now that we've gotten that out of the way, count how many modern games are written for OpenGL, OpenAL, SDL, Allego, or SVGAlib. Now count how many are written for DirectX.
Now if you want people to port to your platform, which is the safer bet?
Sure, you can (and probably will) release your own SDK, but you still have to deal with reality. Game makers have 4 primary platforms right now - PCs, PS2, Xbox, and Gamecube. Xbox gets to leverage PC development since they're not too far off from one another -- you need to change things certainly, but the core engine can remain the same. Mostly. If you're creating a new platform then you may as well either leverage off one of the established platforms, or have one helluva lot of capital behind you to create a new one and lure developers over. Since you'll be going up against Microsoft, Sony, and Nintendo, I really hope you have a lot of capital.
Since two of the four platforms are completely and utterly closed - Nintendo and PS2 - you only have one option to leverage. DirectX. Done right you can actually do better leveraging than the Xbox... although it's not sounding like they're doing this.
Oh, and before you flame me as a Windows bigot, I'm not. Yeah, I use it. I also use Redhat and code for Unix. I prefer Unix. But that doesn't mean I put blinders on and whine about how the world should work instead of understanding how it actually does.
Uh... I don't think you quite get it. Putting your docs in CVS is all well and good (and smart). We do. But that doesn't help a bit with what the poster wants, since CVS doesn't help show changes with binary files. And even if it did, what good is that going to be to you? Heck, even if you used OO.org and stored the doc as uncompressed XML it's not going to help, because you don't want to see the raw data -- you want to see the document.
More importantly, you want to see the document with revisions so that you can accept or reject suggested changes on a per change basis.
Word does this quite well. We've used it extensively during the creation of requirements and specification docs. For operations stuff we use a Twiki, which works better for that. Right tool, right job.
I haven't used OO.org's track changes tools, so I can't comment on them. Word's tools work quite well though.
Why? What's the point? It doesn't have 3D capabilities (at least none worth even mentioning at only 8 MB), and 2D video is old hat nowadays. You can get any number of cards with fully accelerated 2D drivers under Linux. The issue is 3D drivers... and then it's only an issue if you want open source drivers that actually perform to the cards capabilities.
I think you have a complete and total lack of understanding about video cards based on your 8MB vs 32MB comment. You realize that 1600x1200 32-bit 2D video uses only 5.7 MB of memory? There are higher resolutions, but they're rarely used. The only need for more memory is texture buffering and z buffering, which are both purely in the realm of 3D graphics. More memory does not have any impact whatsoever on 2D graphics. In fact, most 3D cards are relatively unconcerned about their 2D speeds because it's all "fast enough" nowadays (and yes, I'm old enough to remember when 2D speed was a key measurement -- and remember getting my first card (a Number9 Imagine128, won at Comdex) that could actually scroll text in a window faster than it could full screen).
Heh. Well, I'm quite literally working on this stuff when not avoiding doing work by reading /., so it's quite fresh. :)
:). All we're really looking to do with Python is a load test tool and some Big Brother monitoring scripts (the latter of which is needing the extention -- that or rewrite a thousand+ lines of C++ for python and then maintain both whenever something changes) so it's not entering into our development in a big way. Yet. But it's unlikely that we'll use any other advanced scripting language at this point, since increasing the number of languages utilized (currently C++, shell script, SQL, and Python, with Java being used in another part of the project) just makes maintainence more and more difficult.
:)
And yes, it is still easier than dealing with Perl-guts... the docs for that (last time I glanced at them, which was years ago) were quite horrid, and I've never tried it myself anyway. Still having issues at the moment (core dump upon import), but investigating the causes and solutions. Things are moving.
The re module does have a sub() function, but that's fairly well documented.
Yeah, but the bit of docs I quoted are from the re.sub() documentation! Like I said, really annoying when it references you to something that doesn't appear to exist.
I just looked back at the tutorial and found the section on the % operator -- which does exactly what I thought it did. I suspected that it wasn't tied to print, and it's definitely a nifty and good way to format things. Thanks for the heads up on where to find it.
As for books, one of my coworkers has the Python 2.1 Bible, which had far better info on some of the aspects of extending Python. It's at least gotten me to the core dump stage
Doing Perl w/o a book is possible... but doing it without a book or the man pages/online versions of same would be a PITA. I don't actually own the Camel or Llama... the man pages are perfectly good for me. I also don't read other people's perl script though
It's going to make waves, but it's still pretty new tech. I work for a company in the industry (no, you've never heard of us unless you're an owner of a freight hauler or line shipper, or maybe one of their data entry people) and it's being looked at now. I suspect the big guys (like UPS and FedEx) are considering it as well.
One thing to consider is that most of the transport industry is deeply low tech. Most handling and tracking is still done with paper, faxes, and telephone calls. AFAIK, we're the first company to even offer end-to-end electronic invoicing in the industry - up until now it's been done with snail mail. And this is a huge, multi-billion dollar industry -- even after you exclude UPS, FedEx, and Airborne. It ranges all the way from shipping aircraft engines for Boeing jetliners to shipping the fridge you bought from the local big box store to your house. And nearly all of it is still done on paper.
Surely not entirely from switching to Linux.
I'd be willing to guess that nearly none of it is from switching to Linux... yes, the OS is free. That's nice. The support is not, and anyone who thinks that the Japanese government is going to run their payroll system without support on every single bit of the system is living in some alternate universe. It may be that the support costs for Linux and the other software (database, payroll, etc) are dramatically lower than it was for the old mainframe systems though.
Additionally, unless they're deploying Linux on the exact same hardware that their old system was running on, you can't credit Linux with the operating cost savings
Well, credit Linux, no... but that may very well be a substantial portion of it. Imagine the cost savings of moving from a few ancient water-cooled mainframes to a modern AS/400 or eSeries server. The water and power savings will be immense.
Overall I'm sure you're correct - Linux is a side note here and not the primary cause of cost reduction.
Dang it, I meant to put in some concrete examples but apparantly forgot. Blergh.
First off, I'm using the Python 2.1 docs -- they may be outdated and the more recent 2.2 or 2.3 docs may be better, but 2.1 is what's installed on our development and production boxes, and we dislike changing those kinds of things unless we need to.
The C API docs stink. There's not a single complete example in the doc tree (on python.org) that I've found -- just snippets here and there. There are references that extending Python is very simple (and, indeed, it does appear to be now that I've found sufficient docs) and there's even tools to automate most of it. But nowhere are the actual tools referenced/linked to, there are calls used without explanation or links to explanation, and the docs suddenly shift between extending and embedding without adequate differentiation.
I dislike the break between the "Extending and Embedding" section and the "Python/C API" section. Yes, one's a tutorial and one's a reference, but the tutorial is thus missing vast amounts of info that are only present in the reference section. Bad.
I'm not real happy with the organization of the Global Module Index. There's a couple hundred default modules, and sometimes you have to go hunting through several different ones to find the desired function. The Library Reference is often lacking in reference as well -- for instance, section 4.2.4 (Regular Expression Objects) describes the re.sub() function which is "Identical to the sub() function, using the compiled pattern". That's nice. Where's the built-in sub() function? It's not in section 2.3 - Built-in functions. Nor is it a string.* function. I've looked in the places that made sense to me, and gave up, using string.replace() instead (which is what is appropriate for my usage, but I'm still wondering). I finally found some documentation on the print statement. In the "Language Reference" section (which makes sense... except that it's subtitled "for language lawyers"). And I'm still wondering about a 'print "bleh %s bleh" % (val)' construct I used... copied from elsewhere, since I can't figure out what the % is doing except by reference. I'm sure it's documented... and I'll eventually find it... but it's annoying right now.
By and large I suspect you're correct -- I'm used to the Perl docs and know where to find things. I'll eventually get used to the Python docs as well. But in the meantime I'm finding it annoying to learn. I should probably go out and pick up the O'Reilly Python book... I learned Perl from reading the Camel (1st ed) and hacking away at things. Doing much the same with Python, but the online docs are frustrating me at the moment due to a lack of global indexing (beyond site wide search which is vast overkill).
PhysicsGenius is a known troll... and it's amusing to see just how many moderators get caught by him. All of his posts have just enough in them to sound intelligent, but they're all very deeply wrong -- usually twisting the facts backwards (such as this one) or flying off into realms of thought usually reserved for the insane.
Maybe some moderators with a clue will beat the grandparent post down now.
On topic - I've known Perl for awhile and am starting to code in Python... the syntax is certainly cleaner, but the docs certainly aren't. To put it kindly, they suck. Yes, if I was sufficiently motivated then I could contribute instead of just bitching, but: A) I'm not, B) I don't know nearly enough Python yet to do it right. I find Perl's documentation to be layed out in a much more rational and useful structure. Shrug.
Since you then have to go back over the entire work, with a single person, to ensure consistancy between chapters (particularly for word choice, idiosynchracies, and word plays) -- still over a month. In fact, it's questionable that you'd save much time at all.
Why on earth was this modded up as insightful? It's not insightful, it's completely offtopic. It's gobbleygook that has nothing at all to do with the article.
Similar things have not been done -- Mapquest doesn't offer anything like this. Sat images don't give this information, and this isn't at all about "getting from Point A to the mall". Nor does it have anything to do with business or marketing, excepting that the entirety of our economy is now dependant upon this seemingly irrelevant infrastructure.
The point is that -- it maps out the infrastructure. Are you going to want to go to the mall if it has no power? Or maybe no inventory, because the power and data lines have been cut to the suppliers? Of course, that presumes you even have gas for the car -- those gas pumps won't do much without power. And while you can still move trucks on the freeway, the supply chain is now totally dependant on computer interaction to indicate when stations need more fuel. It used to be that the data flow was via sat, but it's now done through DSL for stations in major metro areas. Of course, it may be difficult to pay for the gas -- the ATMs won't be able to dispense cash without network access. Your credit cards won't work either - that whole network thing again.
No, you don't need to know the infrastructure. That's the whole point afterall. But other people do -- either for disaster planning (and I'm not talking terrorists here... tornados, earthquakes, floods, and other natural occurances can be enough of a problem), city planning, or other uses. And, yes, there are national security concerns here, but the answer isn't to bury the research -- it's to utilize the research. Use the maps to show where the points of vulnerability are and then diversify them. Build backups and redundancy into the system. Don't ostritch on the problem. No, it's not cheap. And in many cases it's not easy, particularly when faced with natural obstacles like rivers and mountains. But it's doable and necessary.
I would have thought, that the publishers would have learnt their lesson, and made sure that translations into the other languages where Harry Potter has a large fan base would be released on the same day as the english version, or failing that, not more than a month later.
Doing a top quality translation of a 700+ page novel takes more than a month. Even to a language relatively close to English such as German (and while I can't speak German, I did take several German classes in high school... they're sufficiently different to cause massive headaches).
Prior to it's distribution the 5th book was only read by 5 people, one of which was J.K. Rowling herself. They wanted to keep a tight lid on the contents, and they succeeded pretty well -- only in the couple days before release were any books leaked from the distribution chain. If you farm the book out for translations a month or so beforehand (if that's even possible, given how close some authors cut the delivery dates for publishing) then you may as well forget it -- you'll have full copies of the book wandering around within days of releasing it for translation.
That said, I'm rather surprised at how long the lead times are for the translated works... if the publishers are that concerned, then much more than 3 months is unacceptable. If it's a really difficult translation (say to an Oriental tongue or Basque) then 6 months may be understandable... but translating to Czech takes nearly 8 months? Please!
Because you'd be a damn fool to do so.
As it stands, SCO will have to prove that IBM broke its trade secret agreement, which is going to be a damned difficult thing for SCO to do. They're alleging copyright infringement as well but, and this is important, have yet to file a claim in court about any infringement whatsoever. Until they do so what exactly are you going to sue them for? Libel? Good bloody luck. You'd then be on the wrong side of the table -- you'd have to prove that their claims are false without ever seeing any of their documentation. Enjoy! You'll lose that case in a millionth of the amount of time the SCO/IBM case will take. If you even make it to day 2 in court I'll be amazed.
Here's the deal though -- since SCO is bringing the case against IBM they will have to disclose ALL relevant information on the case to IBM. And presumably to the public, unless they somehow get the record sealed (and SCO does not have the political might that AT&T had in the AT&T/Berkeley case). The claimant is not allowed to spring surprises on the defendant in the US court system -- the defendant, being presumed innocent, is privy to all the claims being brought against them as well as all evidence to support those claims. The same is not true in reverse -- IBM can bring out evidence to counter SCO without SCO's lawyers having ever seen it before (this, however, is generally considered bad form and frowned upon not only by the other lawyer, but also the judge -- judges don't like having their time wasted and any such evidence should be shared with the claimant in order to avoid having the case go to trial in the first place).
IBM may bring a countersuit against SCO, but in order to do so they'd have to show some substantive damages to their business model... not a very easy thing to do, particularly when you're the size that IBM is. It also complicates matters, and if IBM thinks they have a solid case they may not feel the need to bring a countersuit... easier just to shut them down quickly rather than turn an already long and complicated case into an even longer and more complicated case. Countersuits seem to be used most often when neither side has a particularly strong case.
It seems to me that some of the players in this game have much more knowledge then they admit openly.
Welcome to reality.
Oh, so now you're going to convince everyone in the world to stop selling military hardware? You realize that the US is hardly the only military power selling its older technology overseas -- France, Britain, Russia, China, and pretty much every other military power does so as well. Oh, and you can't just get an agreement to not sell to the Middle East/SW Asia countries, since most of the arms deals are done through intermediaries.
Not to mention that a large number of arms are embargoed in that area anyway, at least to particular countries such as former Iraq, Iran, Syria, et. al. -- and yet they still buy them and get them through the inspections. No, I'm not talking WMD... I'm talking about things like the French tanks that Iraq acquired after the first Gulf war. I'm not blaming the French here, mind you, because I seriously doubt they intended to sell them to Iraq, but they still wound up there. International arms trade is hardly done above the board. (As it happens, I suspect France would have much rather not had their tanks show up in Iraq... since it showed how pathetically they fared against US tanks, and prior to that time there was a good bit of discussion about which would be better - the fast, light French armor or the slow, heavy US armor. The US armor had twice the range and one shot, one kill capability. The French tanks couldn't even close to fire, and if they did they didn't have the firepower to eliminate a US tank before being destroyed).
Of course, if you did magically shut down the arms trade in the middle east, it wouldn't stop the production of weapons. Most of the countries have factories for the manufacture of small arms -- it doesn't take that much. Israel designs and builds their own tanks as well, so it wouldn't even stop that. You'd cripple the air forces of all the countries, but since Israel has a vastly superior air force to start with it's not going to help the odds that much.
I don't think that's what he meant by a "standard library"
Then why did he explicitly mention the STL?
that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc
Oh, you mean all the OS specific stuff that is horrendously outdated rapidly or is so generic as to be devoid of features and richness? Yeah, shower me with that stuff.
STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
Uh... yes, it is a big whoop. If you don't think so, then might I recommend Pascal? You can even build your own string data type and manipulators!
Oh, btw, the STL does not contain hash tables. GNU's STL has them, but they're an extention to the STL, not part of the actual STL.
As for why it actually is a big deal - the STL is designed, first and foremost, for efficiency. When you ask for a vector you have guarantees about how it's implemented, how efficient certain operations are, and so forth. This is key to an efficient program, and particularly for embedded programming (which was a consideration for anything in the core C++ language or the STL). The same cannot be said for Java, C#, Perl, Python, etc.
I'm not recommending that you use C++ for everything... that's just silly. But for large programs that have to consider execution speed as well as development speed, it's one of the best bets out there right now.
Well, I rather disagree with him on this point... particularly regarding C++.
There is, indeed, a standard library for C++, one which is widely supported - STL. Is there a learning curve? Sure. And you're going to tell me that there isn't a learning curve for any other language, library, or whatever? Please.
I started at my current job a bit over 15 months ago. I knew only the basics of C++, and nothing at all about the STL (or even templates). It took me about a week to be comfortable using the STL, and I could read the code instantly -- there's nothing radical about it.
Are compile times long? They can be... particularly if you need to compile from scratch or change one of the base libraries used. But on modern hardware it's not a huge issue, and consider how much time you'll end up saving users because it's not an interpreted or pseudo-compiled language. Yeah, I like Perl and Python too, but they're not suitable to really large projects, particularly if you need them to scale very widely.
Sure, I knew scrith required more tensile strength than theoretically possible, but I haven't seen any similar calculations for shadow square wire.
Of course, I haven't seen any calculations for SSW at all, so it's still quite possible you're correct.
My pants are entirely plastic free
:) -- but even then it's litter is probably in a plastic container (unless it's an outdoor cat, in which case I really hope it isn't!), good chances that the food/water bowls are plastic, and really good odds that some of its toys are plastic (hell, our youngest cat's favorite toy is a plastic tie wrap).
Doubt it. Odds are, the tags that were on the pants when you bought them were attached with and/or made of plastic. They were probably manufactured with machines containing rather large amounts of plastic, and were shipped in containers partially made of plastic.
my broom
Old broom then. Most of the newer brooms are made entirely of plastic -- yeah, they're the cheap ones. They work just fine too.
books on my shelf
Which probably had theft prevention tags in them which contained plastic.
virtually all the mail I get
What, you mean the magazines that have plastic wrappers, or any of the mail with a plastic clear window? And I've had an increasing number of junk mails that actually used plastic-ish envelopes.
my cat
As you noted, good odds it recently ate something plastic
Yeah, pushing it on some of those, but you know what the OP meant, and he's pretty much correct. There's very little chance that you can entirely avoid the use of plastic nowadays.
Where are the calculations on this? I did some Google searches, but they turned up nothing.
I'm utterly amazed that in the 14 replies thus far, nobody's given you the right answer.
If you want a true, original IBM PC keyboard then go here. They make the originals, complete with massive weight and key klacking, plus modified versions that have the Windows key, integrated mouse, college mascot/color inspired ones, quiet versions, etc... yes, they're pricy by modern day keyboard standards, but if you want a keyboard that will live somewhat longer than all of your descendants there's no other option.
I actually have two original IBM PS/2 keyboards, bought from used computer stores nearby... but the noise annoyed the hell out of my wife and I recently switched to a Memorex multimedia keyboard. It's really not all that bad, and every once in a great while I even remember to use some of the extra keys on it.